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I .     INTRODUCTION 

A .   BACKGROUND 

Although  the  Department  of  Defense  (DoD)  has  had  an 
electronic  messaging  infrastructure  since  the  late  1960s,  with 
the  inception  of  the  Automatic  Digital  Network  (AUTODIN) , 
there  is  a  new  architecture  under  procurement  called  the 
Defense  Message  System  (DMS) . 

This  DMS  infrastructure  will  support  both  organizational 
and  individual  messaging.  The  current  infrastructure,  or  DMS 
baseline,  consists  of  distinctly  separate,  "individual"  and 
"organizational"  messaging  components.  Organizational 
service  is  provided  by  the  AUTODIN,  and  individual  service  is 
provided  by  electronic  mail  applications  on  the  DoD  Internet. 

The  DMS  Program  is  the  result  of  a  1988  Assistant 
Secretary  of  Defense  (ASD/C3I)  effort  to  determine  the  future 
of  DoD  electronic  messaging  systems.  The  areas  that  mandated 
change  were:  (1)  problems  and  costs  associated  with  managing 
the  baseline  system,  (2)  lack  of  an  overall  DoD  messaging 
architecture,  and  (3)  emergence  of  new  international  standards 
and  technology-mandated  change.   (DoD  19  93,  p.  7) 

The  need  to  interconnect  and  interoperate  has  driven  DoD, 
as  well  as  civilian  corporations,  to  develop  international, 
standard-compliant  systems.    Organizations  need  to  exchange 


messages  with  its  components,  clients,  and  competitors  across 
the  boundaries  of  the  proprietary  electronic  mail  packages 
they  may  use.  X.400/X.500  protocols  are  one  means  to  make 
this  interconnection  happen. 

B.   PURPOSE  AND  SCOPE 

The  purpose  of  this  thesis  is  to  provide  DoD  technicians 
and  managers  alike  who  are  associated  with  an  E-Mail  system, 
a  basic,  thorough  discussion  of  the  Consultative  Committee  for 
International  Telegraphy  and  Telephony  (CCITT)  X.400  family  of 
Message  Handling  Standards.  Additionally,  a  brief  definition 
of  the  associated  CCITT  X.500  Directory  standard  is  provided. 
Since  many  corporations  have  already  invested  significantly  in 
various  E-Mail  packages,  specific  platforms  and  operating 
systems,  a  global  messaging  standard  that  transparently  unites 
all  disparate  E-Mail  systems  would  be  ideal.  X.400  and  it's 
directory  counterpart,  X.500  are  CCITT  recommendations  for 
this  evolutionary  messaging  demand.  This  thesis  topic  has 
direct  application  to  DoD  since  it  specifically  discusses 
X.400  implementation  issues  for  the  E-Mail  portion  of  the 
Defense  Message  System  (DMS) .  In  the  conclusive  chapter, 
after  identifying  industry  lessons  learned  on  an  X.400 
installation,  possible  solutions  are  given  for  DoD  components 
on  how  to  incorporate  X.400  into  their  electronic  messaging 
environment.  These  conceptual  solutions  may  assist 
Information  Technology  managers  in  planning  their  messaging 


systems  so  that  they  may  have  the  message  handling 
functionality  of  the  standards  in  the  interim  period  of  the 
X.400-based  DMS  implementation. 

The  scope  of  this  thesis  includes:  discussion  of  the 
evolution  of  the  CCITT  X.400  standard  series;  a  description 
of  how  it  works;  issues  from  a  product  review  and  Corporate 
Computing's  ZD  Labs'  report;  a  look  at  how  the  DMS  Program 
plans  to  implement  X.400;  and  a  snapshot  of  how  Wal-Mart 
Stores  Inc.  is  currently  implementing  a  company-wide,  X.400 
messaging  system. 

C.   EVOLUTION  OF  X. 400 /X. 500  PROTOCOLS 

"Electronic  messaging  can  perhaps  be  said  to 
have  started  around  the  time  when,  in  1851, 
the  New  York  and  Mississippi  Valley  Printing 
Telegraph  Company  (later  renamed  as  the 
Western  Union  Telegraph  Company)  was  founded." 
(Betanov  1993,  p. 2) 

Led  by  this  giant,  common-carrier,  Western  Union  Telegraph 

Company,  message  switching  functionality  was  provided  in  a 

torn  tape  manner  over  telegraph  lines  that  were  usually 

dedicated.   It  wasn't  until  a  hundred  years  later,  in  the 

1960s  and  1970s,  that  this  message  switching  functionality  was 

provided  via  computers .  This  enabled  private  organizations  to 

assemble  their  own  messaging  networks  by  leasing  dedicated 

circuits   from   carriers   and   interconnecting   them   using 

computers  acting  as  switches.      These  switches  were  often 

connected  to  the  telex  network  which  had  been  in  operation 


since  the  1930s.  The  telex  market  was  dominated  by 
organizations  like  large  banks  and  trading  companies  with 
international  operations  as  well  as  industry  groups  with 
international  scope. 

Another  related  development  in  the  1960s  and  1970s  was 
that  of  general-purpose,  packet  switching  networks.  These 
networks  primarily  facilitated  the  task  of  communicating  data 
to  and  from  computers.  The  first  significant  packet  switching 
network  was  the  ARPANET,  sponsored  by  the  Advanced  Research 
Projects  Agency.  Between  1969  and  1977,  ARPANET  grew  from  4 
nodes  to  111  hosts.  Within  packet  switched  networks,  the 
transmission  protocols  had  to  be  separated  from  the  messaging 
and  other  application  protocols  since  messages  were  decomposed 
into  packets  and  sent  packet  by  packet  instead  of  as  one  whole 
entity.  This  division  in  functionality  created  independent 
development  of  both  application  and  transmission  protocols. 
Thus,  software  development  for  these  protocols  and  integration 
of  packet  switching  technology  into  applications  were 
simplified.  The  person  programming  the  application  did  not 
have  to  know  details  of  packet  switching  mechanisms.  The 
developer  just  had  to  know  how  to  use  the  Application  Program 
Interface  (API) .  The  Consultative  Committee  of  International 
Telegraphy  and  Telephoney's  (CCITT)  eventually  provided  formal 
recommendations,  called  X.25  and  X.75  that  represented  packet 
switching.    The  major  result  of  these  protocols  was  to  allow 


easy  interconnection  of  dissimilar  systems  regardless  of 
hardware  platform.  (Betanov,  1993,  pp. 3-4) 

From  the  perspective  of  electronic  mail  applications  and 
services,  the  customized  development  of  X.25  applications 
resulted  in  two  basic  problems:  (1)  hardware  manufactures 
developed  electronic  mail  applications  that  operated  only  on 
platforms  that  they  manufactured  such  that  they  were  not 
compatible  with  those  developed  by  another  manufacturer;  and, 

(2)  electronic  mail  service  providers  allowed  users  access  to 
their  systems  for  sending  and  receiving  messages.  For  example, 
Western  Union  provided  Easylink  service,  MCI  provided  MCIMail 
and  Sprint  provided  Telemail.  However,  these  carriers  offered 
no  connectivity  among  themselves  except  through  telex; 
therefore,  the  services  were  strictly  proprietary.  The 
following  situations  highlight  these  developmental  problems: 

(Betanov,  1993,  pp.  4-5) 

•  An  organization  using  equipment  from  different  hardware 
manufacturers  could  not  easily  connect  E-mail  systems 
running  on  the  various  platforms. 

•  An  organization  could  not  readily  connect  its  proprietary 
E-mail  system  to  a  public  E-mail  system  provided  by  a 
common  carrier  or  service  provider. 

•  Users  of  various  public  E-mail  systems  by  different 
service  providers  were  basically  isolated  from  one  another 
since  these  disparate  systems  had  no  interface  with  one 
another . 

Customized  interface  solutions  to  the  above  problems 

evolved  for  interconnecting  different  hardware  and  software. 

Without  a  standardized  solution,  the  interface-building  wheel 


was  reinvented  over  and  over  again,  users  were  very  frustrated 
and  businesses  spent  a  lot  of  money. 

Industry  began  to  demand  a  messaging  environment  that 
would  provide  common  functionality  across  hardware  platforms 
and  service  providers.  If  the  definition  of  such  an  interface 
could  be  achieved,  not  only  would  it  become  as  easy  to 
interconnect  electronic  mail  systems  as  it  is  easy  to 
interconnect  dissimilar  systems  using  X.25,  but  it  would  also 
be  possible  to  develop  standardized  applications  that  could  be 
invoked  using  APIs.  Theoretically,  an  API  would  remove  the 
requirement  that  a  programmer  know  all  the  details  of  message 
handling  in  order  to  incorporate  messaging  into  an 
application.  A  program  could  be  written  to  "pass"  the  message 
contents  and  selected  service  elements  (ie.,  recipients 
address)  to  the  API  and  the  E-Mail  system  behind  the  API  would 
then  handle  the  specific  details  of  ensuring  the  message  was 
received  at  the  destination. 

Development  of  a  generalized  messaging  system  was 
initiated  in  1975  when  the  United  Nations  Educational 
Scientific  and  Cultural  Organization  (UNESCO)  organized 
"Working  Group  6.5"  through  it's  subcomponent,  the 
International  Federation  of  Information  Processing  (IFIP). 
The  overall  mission  was  to  develop  the  requirements  for  a 
computer-based  messaging  system.  In  1981,  another  organization 
within  the  UN,  CCITT,  which  was  mentioned  earlier,  followed  on 
IFIP's  work.   In  1984,   the  CCITT  X.400  series  of  recom- 


mendations  governing  message  handling  systems  were  ratified. 
(Betanov,  1993,  pp.  5-6) 

By  December  of  1988  service  providers  did  not  appear  too 
anxious  to  change  their  proprietary  status  quo.  Providers  of 
public  E-mail  services  developed  X.400  messaging  capability 
but  were  not  aggressive  to  interconnect  their  respective 
systems.  In  response,  an  industry  group  called  the  Aerospace 
Industry  Association  (AIA) ,  which  happened  to  be  a  very  large 
customer  of  the  E-mail  industry,  invited  all  major  E-mail 
providers  in  the  U.S.  to  participate  in  a  pilot  project. 
Essentially,  all  providers  were  to  connect  their  respective  E- 
mail  systems  via  X.400  to  demonstrate  the  feasibility  of  X.400 
connectivity.  This  AIA  pilot  project  was  extremely  successful 
in  that  all  providers  were  able  to  establish  connectivity  to 
at  least  one  other  service  provider  despite  their  extremely 
different  implementations  and  hardware  platforms.  (Betanov, 
1993,  pp.  6-7) 

In  response  to  industry  demands  as  well  as  the  CCITT 
normal  four-year  review  cycle  for  standards,  X.400  was 
reviewed,  improved  (ie.,  more  readable  and  secure,  better 
interfaces,  and  a  new  message  store  functionality)  and 
completely  re-written  for  ratification  in  1988. 

1988  also  documented  the  adoption  of  a  series  of  CCITT 
recommendations  for  a  directory  system,  called  X.500.  Many  of 
the  CCITT  committee  members  who  developed  the  1988  X.400 
protocols  helped  develop  this  new  set  of  protocols   (Radicati, 


1994)  .  Used  in  conjunction  with  X . 400-compliant  messaging, 
the  X.500  recommendations  proposed  simplification  of  the 
address  determination  and  related  issues  in  X.400 
environments . 

During  1990,  the  U.S. -based  service  providers  became  fully 
interconnected  so  that  a  user  of  any  public  E-mail  service 
could  communicate  with  a  user  of  any  other  public  E-mail 
service.  In  fact,  by  June  of  1992,  many  of  the  service 
providers  had  links  to  providers  located  in  20  to  40  other 
countries.  In  the  1990-1993  time  frame,  the  following 
additional  but  related  developments  occurred:  (Betanov, 
1993,  pp.  8-9) 

•  The  number  of  systems  providing  X.400  interfaces  increased 
sharply.  For  example,  most  E-mail  packages  running  on 
local  area  networks  (LANs)  provide  X.400  gateways  which 
interconnect  individual  LANs  and  other  messaging  systems. 
This  creates  either  a  corporate  electronic  messaging 
backbone  using  X.400,  or  X.400  LANs  connected  to  a  service 
provider's  public  E-mail  system. 

•  February  1990  -  the  North  American  Directory  Forum  was 
created  to  accelerate  the  development  of  a  global  X.500- 
compliant  directory  system. 

•  June  19  91  -  CCITT  promulgated  the  X.43  5  standard  ,  which 
allows  for  the  exchange  of  electronic  data  interchange 
(EDI)  documents  over  X.400  networks. 

•  February  1992  -  a  U.S. -based  vender  of  X.400  products 
announced  a  suite  of  products  that  allow  X.400  connections 
over  telephone  lines,  as  opposed  to  packet  network 
connections.  This  development  reduces  the  cost  of 
maintaining  X.400  connections  allowing  smaller  user 
communities  to  become  integrated  into  the  global  X.400 
network,  thus  increasing  the  user  base  reachable  via 
X.400. 

•  October  1992  -  X.400  Application  Program  Interface 
Association  (XAPIA)   is  a  well-established,   standards- 


setting  organization  composed  of  the  major  E-mail  vendors 
who  have  created  a  set  of  APIs  to  the  X.400  messaging- 
service  standards.  The  association  is  also  working  on  a 
set  of  cross-platform  messaging  APIs  that  will  further 
enhance  the  functionality  of  X.400  (Duffy,  1992,  p.S/25) . 

•  June  1993  -  Many  major  vendors  are  providing  native,  or 
2nd  generation  X.400  implementations  which  are  real,  E- 
mail,  backbone  environments  that  comply  with  the  1988 
X.400  standard  as  opposed  to  1st  generation  1984  X.400 
"mapping"  products  like  proprietary  X.400  gateways 
(Radicati,  1994)  . 

•  September  1993  -  Department  of  the  Air  Force  publishes  its 
Request  for  Proposal  for  the  DMS-GOSIP  Program  specifying 
X.400/X.500  as  mandatory  requirements  for  the  Messaging 
system  (DoAF,  1993) . 


D.   ORGANIZATION 

Chapter  II  characterizes  the  basic  requirements  for  any 
X.400/X.500  enterprise  system.  Chapter  III  will  provide 
X.400  implementation  methods  and  issues  with  an  overview  of  an 
industry  lab  report  from  ZD  Labs  of  Corporate  Computing. 
Chapter  III  also  identifies  the  top  three  industry  E-Mail 
packages  as  well  as  those  used  in  DoD.  Chapters'  IV  and  V 
will  illustrate  the  DMS  and  Wal-Mart  Stores,  Inc.  as  the  DoD 
and  industry  examples,  respectively,  of  X.400/X.500  enterprise 
systems.  Finally,  Chapter  VI  will,  after  recapitulating 
industry  lessons-learned  on  X.400  installations,  provide 
possible  solutions  for  DoD  components  who  want  to  incorporate 
X.400  into  their  electronic  messaging  environment  so  that  they 
may  have  the  functionality  of  the  standards  in  the  interim 
period  of  the  DMS  X.400  implementation. 


II.   X.400/X.500  ENTERPRISE  SYSTEM  REQUIREMENTS 

A.   DEFINITION  OF  X.400/X.500 

In  October  1984,  the  Plenary  Assembly  of  the  CCITT 
accepted  a  standard  to  facilitate  international  message 
exchange  between  subscribers  to  computer  based  store-and- 
forward  message  services.  This  messaging  transport  standard 
is  known  as  the  CCITT  X.400  series  recommendations  and  happens 
to  be  the  first  CCITT  recommendation  for  a  network  application 
(Houttuin.  1993,  p. 5).  In  October  1988,  CCITT  published  a 
totally  rewritten  set  of  standards  which  increased  the 
functionality  of  the  1984  standards.  There  were  five 
significant  improvements  to  the  message  handling  architecture 
that  included  the  Message  Store  (MS),  distribution  lists, 
X.500  directory  services,  support  for  postal  delivery  systems, 
and  security.  In  addition,  X.400  protocol  layering 
architecture  changed  substantially  to  incorporate  recent 
changes  to  the  Open  Systems  Interconnection  (OSI)  upper  layers 
and  to  provide  a  design  that  is  more  consistent  with  other  OSI 
applications.  (Burns,  Radicati,  1992,  p.  179) 

X.400  has  been  defined  as  follows: 

The  primary  role  for  X.400  has  been  to  define 
a  format  for  the  electronic  envelope,  so  that 
an  X.400  backbone  can  transmit  messages 
regardless  of  contents  (Brennan,  1992,  p.S22). 
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If  the  "electronic  envelope"  depicts  the  X.400  role,  then 
the  functional  aspect  of  the  CCITT  X.400  family  of  standards 
can  be  described  as  a  model  for  a  Message  Handling  System 

(MHS)  and  associated  services  and  protocols.  In  the  context 
of  the  MHS,  "users"  may  be  either  humans  or  application 
processes.  The  User  Agent  (UA)  is  a  process  that  makes  the 
services  of  the  MHS  available  to  the  user.  The  services  are 
grouped  into  message  transfer  services  and  interpersonal 
messaging  services.  These  services  are  further  divided  into 
three  categories:  basic,  essential  optional,  and  additional 
optional.  To  illustrate  these  categories,  Table  2-1  lists 
the  services  provided  by  the  Message  Transfer  Agent  (MTA) 

(Stallings  1991,  p. 745) 

The  CCITT  X.400  family  of  standards  for  Message  Handling 

Systems  is  identified  below: 

•  X.400  This  number  represents  the  Systems  and  Service 
Overview  and  defines  the  message  handling  system  model. 
It  consists  of  Uas  and  MTAs,  discusses  naming  and 
addressing,  defines  interpersonal  messaging  and  message 
transfer  services  as  well  as  protocols  for  implementation. 


•  X.402  This  number  represents  the  Overall  Architecture 
and  serves  as  a  technical  introduction  to  it. 

•  X.403  This  number  represents  Conformance  Testing 
specifying  the  criteria  for  acceptance  of  an 
implementation  as  conforming  to  the  X.400  family  of 
recommendations . 

•  X.407  This  number  represents  Abstract  Service 
Definition  Conventions  and  defines  techniques  for  formally 
specifying  the  distribution  information  processing  tasks 
that  arise  in  message  handling. 
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TABLE  2-1:  BASIC  AND  OPTIONAL  SERVICES  PROVIDED  BY  THE  MTA 


Message  Transfer  Agent 


Basic  Services 


Acess  Management 
Content  type  indication 
Convened  indication 
Submit/Deliver  Time  Stamp 
Message  Identification 
Nondelivery  notification 


Enables  UA  to  submit  and  have  msgs  delivered  to  it 

Specified  by  originating  UA 

Specifies  any  conversion  being  performed  on  msgs  being  delivered. 

Both  times  are  supplied  with  each  msg. 

Unique  identifier  for  each  msg. 

Msgs  cannot  be  delivered. 
Registered  encoded  info  types       Allows  UA  to  specify  types  that  can  be  delivered  to  it. 
Original  encoded  info  types  Specified  by  submitting  UA  and  supplied  to  receiving  UA. 

Essential  Optional  Services 

Alternate  recipient  allowed  Deliver  to  alternate  if  designated  recipient  not  found. 

Deferred  delivery  Deliver  no  sooner  than  specified  date  and  time. 

Deferred  delivery  cancellation  Abort  delivery  of  deferred  msg. 

Delivery  notification  Notify  originator  of  successful  delivery. 

Disclosure  of  other  recipients  Disclosure  list  of  other  recipients  to  recipient 

Grade  of  delivery  selection  Request  urgent,  normal  or  non  urgent 

Multi-destination  delivery  Specify  more  than  one  recipient 

Conversion  prohibition  Prevents  MTS  from  conversion 

Probe  Determines  if  msg  could  be  deliverable 

Additional  Optional  Services 

Prevent  non-delivery  notice  Supress  potential  non-delivery  notification 


Return  of  contents 
Explicit  conversion 
Implicit  conversion 


Return  msg  contents  if  non  delivery 

Specifies  specific  conversion 

Perform  all  necessary  conversions  on  all  msgs  without  explicit  instruction 


Alternate  recipient  assignment      Request  designation  of  requesting  UA  as  alternate  recipient 

Hold  for  delivery  Requests  that  msgs  intended  for  specific  UA  be  held  in  the  MTS  until  sue 

specific  time 
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•  X.408  This  number  represents  Encoded  Information  Type 
Conversion  Rules  to  allow  dissimilar  devices  to  exchange 
messages.  The  encoded  information  types  that  are  handled 
include  Telex,  Teletex,  ASCII  terminals,  facsimile,  and 
videotex. 

•  X.411  This  number  represents  the  Message  Transfer  Layer 
conceptually  defining  the  message  transfer  layer  service 
and  the  message  transfer  protocol. 

•  X.413  This  number  represents  the  Message  Store  defining 
its  services . 

•  X.419  This  number  represents  Protocol  Specifications 
defining  the  protocols  for  accessing  the  MTS,  the  MS  and 
those  that  are  used  between  MTAs  to  provide  for  the 
distributed  operation  of  the  MTS. 

•  X.420  This  standard  defines  the  services  provided  by 
interpersonal  messaging  and  procedures  for  providing  those 
services.  (Stallings,  1992,  p. 738) 

Ratified  in  1988,  X.500  is  the  CCITT  standard  that  will 

provide  the  Global  Directory  Services  for  X.400.    X.500 

provides  for  naming  facilities  over  networks,  and  it  enhances 

the  X.400  addressing  mechanism  by  improving  mail  addressing 

within   large,   distributed  message  systems.     Linked  but 

dissimilar  E-mail  systems  can  now  have  common  directories,  a 

feature  that  hides  complex  addressing  schemes  from  users. 

These  directories  are  maintained  on  X.400   file  servers. 

Directories  can  be  accessed  independently  by  any  number  of 

components,   including  Uas,   MTAs,   Access  Units   (AUs)   and 

Message  Store  (MS)  facilities,  and  even  directly  by  end  users. 

(Burns,  Radicati  1992,  pp. 180-182).    These  components  are 

fully  defined  in  the  next  section. 
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B.   HOW  AN  X. 400 /X. 500  MESSAGE  HANDLING  SYSTEM  WORKS 

In  an  X.400  system,  users  are  provided  with  the  capability 
of  sending  and  receiving  messages.  The  interface  to  the 
actual  user  (whether  human  or  process)  is  accomplished  through 
the  User  Agents  (Uas)  .  For  example,  a  UA  may  be  implemented 
in  the  MHS  as  a  computer  program  that  provides  utilities  to 
create,  send,  receive  and  archive  messages.  Each  UA  is 
provided  a  "name"  so  that  the  Message  Transfer  System  (MTS) 
can  transfer  messages  from  an  identified  originating  UA  to  a 
specific  receiving  UA.  Basically,  Uas  pass  messages  to  Message 
Transfer  Agents  (MTAs)  until  the  messages  reach  their 
destinations.  As  shown  in  Figure  2-1,  which  illustrates  the 
components  of  a  distributed  messaging  system,  the  actual  work 
of  message  transfer  is  done  in  the  MTS  by  the  MTAs.  Prior  to 
forwarding  the  message  to  another  MTA  or  a  UA,  the  MTA 
validates  the  submission  envelope  and  performs  housekeeping 
functions  such  as  recording  submission  time  and  generating  a 
message  identifier.  Although  not  pictured  in  Figure  2-1,  it 
is  important  to  note  that  the  MTA  may  store  the  message  in  a 
"mailbox"  facility  called  a  Message  Store  (MS)  to  be  picked  up 
later  by  a  UA.  Sometimes  the  MTA  that  accepts  submission  of 
a  message  delivers  it  directly  to  a  UA  or  MS.  Given  the 
functionality  of  the  MS,  it  could  conceptually  be  located 
throughout  the  MHS  and/or  on  the  logical  boundary  between  the 
MHS  and  the  MTS.  Other  scenarios  require  MTAs  to  relay  the 
message  to  one  another  until  it  reaches  its  destination. 
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Figure  2-1:  Components  of  a  Distributed  Messaging  System 
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Using  such  a  relay  eliminates  the  need  to  have  all  UAs  and 
MTAs  available  on  a  24-hour  basis;  and,  combined  with  the  MS 
component,  allows  the  office  to  "shut  down"  at  night.  The 
specific  functionality  of  the  MS  can  be  defined  as  follows: 

•  One  MS  acts  on  behalf  of  one  user  (ie.,  one  originator/ 
response  address) . 

•  When  a  UA  subscribes  to  a  MS,  all  messages  destined  for 
the  UA  are  delivered  to  the  MS.  When  a  message  is 
delivered  to  a  MS,  the  role  of  the  MTS  in  the  transfer 
process  is  complete. 

•  The  MS  stores  only  delivered  messages,  not  those  being 
submitted. 

•  An  "alert"  may  be  requested  when  a  certain  message 
arrives . 

•  Message  submission  from  the  UA  to  its  MTA,  via  the  MS,  is 
transparent . 

•  Users  are  provided  with  basic  message  management 
facilities  such  as  selective  message  retrieval,  delete  and 
list . 

In  effect,  the  MS  specification  is  simply  a  standardized 
definition  of  how  otherwise  local  UA  functions  have  been  taken 
over  by  a  separate  system  and  accessed  via  a  protocol. 
However,  prior  to  the  1988  specification,  messages  sent  from 
the  UA  to  the  MTA  could  be  lost  if  the  MTA  was  not  ready  to 
accept  them.  The  lights  had  to  be  on.  So,  the  MS  was 
critical  to  expanding  the  functionality  of  X.400.  (Stallings 
1991,  p. 738-740) 

Finally,  X.400  also  facilitates  communication  between 
different  E-mail  systems  by  acting  as  a  translator.  An  Access 
Unit    (AU)   provides  a  gateway  between  the  MHS  and  the  external 
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communication  service  such  as  TELEX.  The  rules  for  conversion 
of  coded  information  are  defined,  making  standardization  of 
the  conversion  of  message  contents  for  transfer  between 
dissimilar  systems  possible.  Figure  2-2  depicts  the  process 
of  message  construction  and  transmission.  Outside  the  scope 
of  X.400,  the  user  prepares  the  body  of  a  message  using,  for 
instance,  a  word  processor.  The  user  presents  the  message 
body  together  with  a  description  such  as  the  subject, 
recipient  and  priority  to  the  UA.  The  UA  appends  a  header 
containing  this  qualifying  information  to  the  message.  The 
MTA  appends  an  envelope  to  the  message  containing  the  source 
and  destination  addresses  and  other  control  information  needed 
for  relaying  the  message  throughout  the  network.  (Stallings, 
1991,  p. 741) 

An  example  of  the  format  for  a  standard  X.400  message 
address  for  an  E-mail  network  is 

c={  }/admd={  }/prmd={  }/o={  }/s={  }/g={  } 
where  c=country;  admd=administrative  management  domain;  prmd= 
private  management  domain;  o=organization;   s=surname;  and 
g=given  name   (Burns,  Radicati  1992,  p. 175).   Using  the  above 
format,  a  typical  address  might  be: 

c=US/admd=telmail/prmd=NPS/o=ms/s=msdosl 

As  mentioned  in  the  previous  section,  X.419  is  the  part  of 
the  X.400  standard  providing  protocol  specifications.  How  do 
these  protocols  work?  Basically,  they  are  located  in  the 
application  layer  (layers  6  or  7  of  the  model  depending  on  the 
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Figure  2-2:  Message  Construction  and  Transmission  Process 
in  a  Messaging  System 


representation  of  the  model)  of  the  OSI  model.  It  is  assumed 
that  the  lower  layer  protocols  used  in  the  OSI  network  model 
are  compatible  between  disparate  systems. 

The  X.419  protocols  consist  of  (1)  the  Message  Transfer 
Protocol  (PI)  which  acts  as  the  "backbone  switching"  protocol 
that  relays  messages  and  other  interactions  among  various 
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MTAs ;  (2)  the  Remote  UA  Access  Protocol  (P3)  which  acts  as  a 

remote  procedure  call  by  enabling  a  UA  that  is  remote  from  its 

MTA  to  obtain  access  to  the  MTS;  and  (3)   the  MS  Access 

Protocol   (P7)   which  provides  a  mailbox  facility.      The 

following  is  an  example  of  the  use  of  these  protocols: 

User  A  sends  a  message  to  User  B  and  User  C.  The  message 
is  handed  over  to  User  A's  UA,  which  submits  the  message 
after  putting  it  in  an  envelope.  The  envelope  is,  in 
effect,  the  header  of  a  P3  protocol  data  unit.  The  MTAs 
take  over  the  transfer  of  the  message  until  it  reaches  an 
MTA  which  can  make  a  delivery  of  the  message.  The  routing 
of  the  message  among  the  MTAs  is  accomplished  with  the  PI 
protocol.  The  recipient,  User  B,  gets  delivery  to  B's  UA, 
via  protocol  P3,  where  it  can  be  directly  read.  For 
recipient,  User  C,  a  copy  of  the  message  is  delivered  into 
C's  MS  from  where  it  can  later  be  retrieved  via  protocol 
P7.  (Stallings  1992,  pp. 743-744) 

C.   ISSUES  FOR  AN  X. 400 /X. 500  ENTERPRISE -WIDE  SYSTEM 

Since  X.400  works  independently  with  respect  to  any  one 
operating  system,  it  is  ideal  for  global  communications. 
However,  there  are  a  number  of  issues  that  need  to  be  taken 
into  account  prior  to  implementing  an  X.400/X.500  enterprise- 
wide  system.  Most  of  these  issues  will  be  highlighted  in  the 
next  chapter  which  provides  methods  for  obtaining  X.400 
functionality  as  well  as  some  product  information. 

First,  there  are  few  X.400  (1988)  products  because  the 
majority  of  the  vendors  who  invested  research  and  development 
in  X.400  did  so  with  the  1984  standard.  This  leads  to  a 
related  issue;  since  the  1984  specifications  were  not 
completely  thought  out,  vendors  have  basically  had  to  rewrite 
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their  1984  products.  Many  vendors  still  feel  this  is  risky  as 
well  as  costly,  and  have  therefore  been  slow  to  do  so. 
(Korzeniowski,  1993,  p.NP4) 

Secondly,  there  is  a  lack  of  domestic  interest  and  support 
in  the  OSI  Model,  on  which  X.400  is  based.  The  TCP/IP  Internet 
has  made  a  "de  facto"  standard  network  model.  The  E-Mail  on 
the  TCP/IP  Internet  is  supported  by  the  Simple  Mail  Transport 
Protocol  (SMTP) .  SMTP  gained  widespread  acceptance  in  three 
years  compared  to  nearly  a  decade  for  its  OSI  counterpart, 
X.400.  Nevertheless,  industry,  in  general,  has  accepted  X.400 
as  the  standard  of  the  future  since  it  has  the  potential  to 
provide  much  more  functionality  than  SMTP.  Yet,  many  industry 
experts  believe  E-mail  customers  want  to  keep  the  TCP/IP 
infrastructure  for  their  messaging  transport  mechanism. 
Figure  2-3  illustrates  this  dilemma  with  the  ISO  Development 
Environment  (ISODE)  link  between  X.400/X.500  and  TCP/IP  as  a 
possible  interim  solution  until  the  ideal  network  messaging 
model  is  achieved. 

As  Chapter  III  will  illustrate,  corporations  who  have 
invested  in  X.400/X.500  have  discovered  it  requires  a  fair 
amount  of  customization  before  deployment.  So,  the  third 
issue  is  that  if  a  company  or  agency  desires  to  implement  an 
X.400/X.500  messaging  environment,  it  will  most  likely 
experience  transition  problems.  Time  and  expert  personnel 
must  be  scheduled  to  iron  out  implementation  bugs.  This 
phenomenon  is  primarily  due  to  vendors  interpreting  and 
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implementing  the  X.400  series  recommendations  differently  in 
their  products.  Consequently,  X.400  can  be  viewed  as  a 
standard  that  provides  a  common  set  of  messaging  features  and 
not  a  full-blown  integration  tool.  (Korzeniowski ,  1993,  p.NP6) 
Finally,  with  respect  to  directory  services,  E-mail 
vendors  using  the  X.500  (1988)  specification  often  add 
proprietary  extensions  to  handle  directory  updates  since  the 
spec  does  not  have  this  aspect  automated.  Thus,  it  still  calls 
for  manual  updates.  The  1992  X.500  specification  improves 
directory  synchronization,  but  products  and  services  based  on 
this  specification  may  not  be  available  for  four  or  five  more 
years.   (Burns,  Radicati,  1992,  p. 182) 
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These  issues  provide  serious  challenges  for  Information 
Systems  managers  as  they  administer  or  create  architecturally 
efficient  and  effective  messaging  infrastructures. 
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III.    X.400/X.500  IMPLEMENTATION  ISSUES 

While  both  the  Department  of  Defense  services  and  agencies 
as  well  as  companies  flatten  their  organizational  structures 
and  pull  together  merged  commands  or  business  units, 
Information  Systems  (IS)  managers  are  seriously  challenged  as 
they  try  to  physically  and  logically  connect  all  the  different 
E-mail  systems.  As  defined  in  the  previous  chapter, 
incorporating  the  CCITT  X.400  series  recommendations  into  the 
messaging  infrastructure  is  one  way  to  accomplish  this .  This 
chapter  will  introduce  three  methods  of  obtaining  X.400 
services  and  discuss  the  integration  of  them  with  excerpts 
from  a  ZD  Labs  report.  (Burns,  Radicati,  1992,  p. 168)  The 
report  illustrates  how  well  X.400  technology  and  products 
performed  during  a  test  of  X.400  connectivity  in  a  "typical" 
corporate  computing  environment. 

A.   ALTERNATIVE  METHODS 

Basically,  there  are  three  methods  by  which  X.400  services 
can  be  obtained:  (1)  connect  through  a  public  E-mail  service 
provider;  (2)  establish  a  corporate-wide  X.400  mail  handling 
system;  or  (3)  install  proprietary  E-mail  packages  with  X.400 
gateways  and/or  servers. 
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1.  Public  X.400  E-Mail  Service  Providers 

Public  E-mail  providers  are  the  fastest  and  simplest 
way  to  set  up  X.400  links.  They  offer  a  subscription  similar 
to  telephone  service  in  that  they  provide  installation, 
configuration,  maintenance  and  support  as  part  of  the  service. 
The  subscriber  usually  pays  a  set-up  charge  and  a  "per 
message"  charge  based  on  usage,  typically  30  to  95  cents  per 
message.  For  businesses  that  are  light  on  mail  traffic, 
public  E-mail  providers  are  most  cost  effective  since 
installation  costs  are  low  and  the  providers  take  on  the 
burden  of  integration  and  management  issues .  They  also 
provide  enhanced  services  like  accounting  and  monitoring.  The 
disadvantage  of  using  public  E-mail  providers  includes 
escalating  costs  as  E-mail  volume  rises,  less  control  over  the 
E-mail  links,  and,  possible  privacy  and  security  risks. 
(Burns,  Radicati,  1992,  pp. 168-169) 

All  the  big  carriers,  AT&T,  MCI  and  Sprint,  have  X.400 
gateways  that  they  manage  for  their  subscribers,  although  they 
typically  do  not  use  X.400  internally.  Their  Electronic 
Messaging  packages  are  called  AT&T  Easylink,  Sprint  Mail  and 
MCI  Mail.  (Lotus,  1993,  p. 4) 

2.  Corporate-Wide  X.400  Mail  Handling  System 

This  option  for  X.400  connectivity  requires  purchase 
of  the  hardware  and  software  needed  to  build  in-house  X.400 
services.  The  advantages  of  this  strategy  include  complete 
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control  over  the  E-mail  system,  its  security  and  performance. 
Additionally,  it  offers  better  integration  with  existing 
corporate  computing  and  data  processing  functions  than  public 
link  services  do.  The  primary  disadvantage  with  installing  a 
corporate-wide  X.400  mail  handling  system  is  the  burden  it 
places  on  the  MIS  personnel  with  planning,  design, 
configuration,  product  compatibility  issues,  and  day-to-day 
maintenance  and  support. 

If  a  corporation  decides  to  build  its  own  X.400 
infrastructure,  there  are  a  number  of  minicomputer  vendors 
such  as  DEC  and  HP  that  provide  all  the  components  needed  for 
storing  and  routing  X.400  messages.  In  most  cases,  these 
vendors  have  adopted  X.400  capabilities  on  their  own  sites  and 
are  actively  promoting  an  architecture  that  they  use  on  a  day- 
to-day  basis.  DEC  is  one  of  the  few  vendors  that  also  offers 
an  X.400  client  or  UA,  which  is  the  front  end  or  user 
interface  to  the  messaging  system.  Most  vendors  use 
proprietary  UAs  and  E-mail  servers  that  link  to  X.400 
gateways,  as  will  be  discussed  next.  (Burns,  Radicati, 
1992,  p. 169) 

3.   Proprietary  E-Mail  System  With  X.400  Gateway 

Most  PC-based  E-Mail  vendors  and  minicomputer  and 
mainframe  computer  messaging  systems  have  X.400  gateways 
between  their  proprietary  messaging  systems  and  X.400  (Burns, 
Radicati,  1992,  p. 169).   Vendors  make  their  proprietary  mail 
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servers  "talk"  to  a  gateway  prior  to  accessing  X.400  MTAs . 
Some  X.40  0  gateways  perform  a  conversion  between  the  vendor's 
own  proprietary  mail  protocol  and  X.400  protocols.  On  the 
other  hand,  a  number  of  third-party  vendors  such  as  Retix, 
DEC,  World  Talk  and  Soft-Switch  provide  X.400  gateways  and/or 
servers  for  connecting  dissimilar  messaging  services  from 
different  E-Mail  vendors.  These  products  support  not  only  a 
wide  selection  of  proprietary  protocols  but  also  provide  the 
message  handling  agents  (UAs  and  MTAs)  required  for  sending 
X.400  messages.  Some  of  these  products  include  directory 
services  that  tie  together  dissimilar  E-mail  directory 
formats.  At  the  high  end  of  the  X.400  gateway  market,  Soft- 
Switch  has  the  most  comprehensive  and  technically  advanced 
product;  however,  it  requires  a  mainframe  and  is  relatively 
expensive,  at  approximately  $100,000  for  hardware  and  software 
versus  a  PC-based  solution  such  as  Retix' s  listed  at 
approximately  $5500.  Retix  has  incorporated  an  effective 
strategy  of  developing  a  wide  range  of  software  options  that 
allow  most  of  the  popular  PC-LAN  messaging  systems,  such  as 
Microsoft  Mail,  cc:Mail,  and  Novel  MHS,  to  access  its 
OpenServer  400  MHS  thus  increasing  the  number  of  different 
MHSs  a  corporation  can  link  with.  (Burns,  Radicati,  1992, 
p. 172)  Figure  3-1  illustrates  a  possible  configuration  for 
some  of  the  X.400  gateways  and/or  servers. 

The  decision  of  whether  or  not  to  use  a  single,  multi- 
protocol  gateway  or  a  multiple-gateway  solution  depends 
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X.400  GATEWAY 


X.400  GATEWAY 


Figure  3-1:  X.400   Connectivity   of   Proprietary   E-Mail 
Packages 

largely  on  the  composition  of  the  installation.  In  general, 
it  is  best  to  minimize  the  number  of  gateways  because  their 
installation,  configuration,  maintenance  and  support 
requirements  vary.  Using  a  third  party  product  that  provides 
interoperability  among  all  the  installed  environments  and 
X.400  is  the  preferred  way  of  reducing  the  number  of  gateways 
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needed  for  a  company's  messaging  requirements.     (Burns, 
Radicati,  1992,  p. 172) 

In  light  of  the  three  methods  of  obtaining  X.400 
services  that  were  described  in  the  preceding  pages, 
implementation  of  X.400  in  a  particular  business  may  require 
one,  two  or  all  three  of  those  methods.  A  business  must 
consider  the  number  of  users,  the  number  of  different  mail 
systems  that  need  to  be  connected,  and,  the  level  of  in-house 
support  available. 

B.   EVALUATION  OF  INTEGRATED  X.400  ENVIRONMENT:  ZD  LAB  REPORT 

Corporate  Computing,    in  its  June/July  1992  issue,  analyzed 

the  conditions  for  implementing  and  managing  an  X.400  system 

in  a  corporate  environment.  Specifically,  their  scenario  was 

a  large  business  with  different  departments  running 
isolated  E-mail  systems.  The  goal  was  to  provide 
companywide  communications  by  linking  the  various  mail 
systems  using  X . 400-compliant  products.  (Burns,  Radicati, 
1992,  p. 174) 

1 .   Methodology 

To  evaluate  X.400  technology  and  products,  Corporate 
Computing  and  ZD  Labs  designed  and  built  an  integrated, 
multivendor,  multiplatf orm  mail  system.  They  used  an  X.400 
backbone  and  gateways  from  a  variety  of  vendors  linking  PC- 
based  LAN  E-mail  systems  with  Unix  VAX  and  mainframe  E-mail 
systems.  They  also  connected  to  public  E-mail  providers  and 
to  third-party  E-mail  integration  packages.  They  examined 
the  pitfalls  and  advantages  of  X.400  from  the  perspective  of 
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the  corporate  E-mail  decision-maker.  They  wanted  to  know  how 
much  expertise  was  required  to  successfully  install  X.400 
products  as  well  as  compare  the  capabilities  of  X.400 
messaging  with  those  of  typical  E-mail  systems.  Finally,  they 
looked  for  differences  in  ease  of  use  and  manageability.  The 
E-mail  integration  challenge  is  summed  up  in  Figure  3-2. 
(Burns,  Radicati,  1992,  p. 168) 


*  Mall  Gateways 
*  Corporate  Backbones 

*  Leased  Lines 
*  Directory  Services 

*  Administration 

Management 

Domains 


PC  Based 
E-Mail 

*  cc:Mail 

*  Da  Vinci 
E-Mail 

*  MS  Mail 
*MHS 


Figure  3-2:  The  E-mail  Integration  Challenge 
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The  products  tested  by  ZD  labs  were  installed  on  the 
following  platforms:  DOS,  Windows,  Macintosh,  Unix,  VAX,  and 
VM    (IBM  Systems/370)1 . 

The  E-mail  packages  included:  Microsoft  Mail  version 
2.1  (DOS,  Mac,  OS/2  and  Windows);  Lotus'  cc:Mail  version  3.1 
(DOS,  Mac,  OS/2  and  Windows);  HP  OpenMail  V. A. 00 . 02 . 03  ;  and 
DEC  All-in-1  Mail  for  VMS  version  4.1;  and  IBM  PROFS  Release 
2.21. 

The  Gateways  were  Microsoft  Mail  Gateway  to  X.400 
version  3.0,  Retix  cc:Mail  X.400  gateway,  DEC  Message  Router 
X.400  Gateway  version  2.2,  Hewlett-Packard  HP  X. 400/9000 
c.02.00,  and  Soft-Switch  X.400   Gateway   version  1  level  3.2 


1  The  DOS,  Windows,  and  OS/2  workstations  were,  specifically, 
Gateway  2000  80386/33c  PCs  with  120MB  hard  drives  and  8MB  of 
memory.  An  Ethernet  Novell  NE  2000T  network  interface  card  was 
installed  in  each  workstation. 

The  Macintosh  workstations  were  MAC  HCis  with  8MB  of  RAM, 
System  7.0.1,  and  a  Technology  Work  Nu-Bus  lOBase-T  Ethernet 
adapter . 

The  DEC  VAX  system  was  a  VAXserver  3100  Model  48  with  24MB 
RAM  and  over  1.5  gigabytes  of  hard  disk  storage.  Unix  ran  on  an 
HP9000/825  with  32MB  of  memory  and  a  400MB  hard  disk.   Finally, 
PROFS  was  accessed  through  a  3270  terminal  connected  to  an  IBM 
System/370  located  at  Soft-Switch.  (Burns,  Radicati,  1992,  p. 172) 

The  Microsoft  X.400  gateway,  Retix  Open  Server  400  and 
Retix  X.400  cc:Mail  gateways  ran  on  the  same  Gateway  2000 
workstations.  The  Microsoft  Mail  gateway  was  connected  to  the 
Retix  Server  through  an  Eicon  EiconCard  HSI/PC  X.25  interface  card 
and  a  Black  Box  Modem  Eliminator.  The  Retix  server  also  included 
a  Retix  PC320  X.25  adapter  with  a  PC321  daughter  board. 

The  HP  X.400  gateway  ran  on  the  HP  9000/825  and  the  DEC 
Message  Router  X.400  was  installed  on  the  DEC  VAXserver  3100/825. 
Soft-Switch's  X.400  Gateway  ran  on  a  25-MHz  80386  Data  General  with 
an  Eicon  X.25  card.  (Burns,  Radicati,  1992,  p. 172) 
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Connectionwise,  the  PCs  were  linked  to  a  Cabletron 
lOBase-T  Hub.  The  network  file  services  were  provided  by 
Novell  Netware  3.11  with  Netware  for  Mac  installed.  The  E- 
mail  network  was  tied  together  with  Retix's  Open  Server  400, 
SprintMail,  and  Soft-Switch  X.400  Gateway.  Figure  3-3 
illustrates  the  E-mail  test  start-up.  (Burns,  Radicati,  1992, 
p. 172) 

Before  starting  the  tests,  the  ZD  Labs  engineers  and 
the  participating  vendors  agreed  upon  the  addressing  and 
configuration  parameters  such  as  the  1984  implementation  of 
the  X.400  standard  and  its  originator/recipient  addressing 
model.  To  test  the  installation  and  configuration  of  the 
X.400  E-mail  system,  they  accomplished  the  following:  First, 
the  ZD  Labs  engineers  and  the  appropriate  vendor  technicians 
set  up  and  tested  each  E-mail  package  as  an  isolated  system 
until  it  was  up  and  running.  Second,  they  set  up  and  tested 
the  X.400  gateways  until  they  were  up  and  running.  Third,  the 
engineers  established  links  by  installing  MTA  software, 
reliable  transport  services  (RTS) ,  transport  stacks  (X.25  and 
LAN),  routing  tables  and  link  information.  Each  system  had 
unique  X.400  setup  procedures  and  components.  Finally,  they 
evaluated  full  E-mail  integration  by  verifying  that  messages 
could  be  sent  and  received  between  all  systems  simultaneously. 

Two  illustrations  of  the  required  connectivity  for 
successfully  passing  a  message  between  two  different  E-mail 
systems  are  illustrated  in  Figure  3-4.    (Burns,  Radicati, 
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Figure  3-3:   ZD  Labs  E-mail  Test  Setup 
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1992,  p. 175)  Messages  addressed  to  users  on  the  same  E-mail 
system  did  not  pass  through  X.400  gateways.  Generally, 
messages  addressed  to  users  on  other  mail  systems  were  routed 
through  the  Retix  mail  server  which  primarily  acted  as  a 
central  hub  that  supported  the  X.400  backbone. 
2.   Evaluation 

Within  two  days,  Microsoft  Mail,  Retix  Open-Server, 
Hewlett-Packard  Open  Mail,  Lotus  cc:Mail,  and  SprintMail  were 
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exchanging  simple  messages  over  Ethernet  and  X.25  links.  The 
only  E-mail  system  they  were  unsuccessful  in  linking  to  other 
packages  was  DEC'S  All-In-1.  Messages  were  passed  through  all 
X.400  gateways  with  the  exception  of  DEC'S  VAX-based  Message 
Router  X.400. 

As  with  all  MHSs,  X.400  addressing  must  be  exact. 
However,  X.400  addressing  is  more  complex,  with  more 
components  than  the  addressing  protocols  associated  with  most 
E-Mail  systems.  Usually,  the  system  administrator  handles 
this  aspect  by  typing  the  correct  name  and  address  into  the 
"local"  address  book.  Problems  may  arise  when  a  user  attempts 
to  address  a  remote  recipient  by  himself. 

In  general,  headers  and  even  the  text  format  (mostly 
line-spacing  and  tabs)  changed  as  messages  transferred  from 
one  MHS  to  another.  Additionally,  the  gateways  in  the 
prototype  network  handled  small  file  attachments,  but  were 
unable  to  handle  large  (two  or  three  megabyte)  files. 
Finally,  most  error  messages  and  non-delivery  notices  were 
sporadic  or  not  helpful  in  identifying  the  problem.  (Burns, 
Radicati,  1992,  pp. 176-178) 

3.   X.400  Lessons  Learned  by  Corporate  Computing 

Overall,  interoperability  among  the  MHSs  was  good  and 
the  X.400  implementations  were  reliable .  The  transport  or 
implementation  of  specific  features  by  the  UAs  was  where  most 
of  the  problems  were  experienced  rather  than  problems  directly 
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related  to  the  X.400  standard.  Installation  and  debugging 
were  challenging  for  both  ZD  Lab  technicians  and  vendors. 
However,  despite  what  they  experienced,  they  believe  that,  in 
general,  once  a  MHS  is  stable  and  its  behavior  understood, 
changes  will  be  far  easier  to  make  and  daily  operations 
smoother . 

Assembling  this  complex,  wide-area  network  did 
require  a  working  knowledge  of  network  architecture,  transport 
protocols,  packet-switched  networks  and  X.400  specifications. 
Although  installation  time  was  enhanced  with  the  very  best 
available  technical  resources  (the  X.400  vendors  themselves), 
it  took  more  time  than  anticipated  to  configure  each  MHS '  s 
options.  Broad  knowledge  about  client-server  operating 
systems  and  mail  applications  was  also  essential  during 
installation.  (Burns,  Radicati,  1992,  p. 178) 

Nina  Burns  and  Sara  Radicati  also  give  the  following 
guidelines  that  may  improve  a  business 's  X.400  implementation: 

•  Contract  with  vendors  or  reliable  third  party  service 
providers  to  help  with  initial  design,  planning, 
installation  and  configuration,  especially  if  you  don't 
have  specific  expertise  in  house.  This  will  pay  for  itself 
many  times  over. 

•  Train  support  people  so  you  build  expertise  in-house  and 
can  maintain  your  systems  in  the  long  run. 

•  Try  to  minimize  the  number  of  vendors  involved  in  the 
construction  of  your  system.  For  example,  it  may  be  a 
better  approach  to  purchase  all  gateways  from  one  vendor 
rather  than  individual  gateways  from  each  vendor.  Many 
companies  are  consolidating  their  E-Mail  systems  so  they 
only  need  to  support  three  or  four  rather  than  eight  or 
ten. 
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•  If  you  purchase  equipment  from  more  than  one  vendor,  bring 
them  all  together  at  the  same  time  during  installation. 
In  addition,  make  sure  you  ask  about  interoperability 
testing  to  ensure  that  the  equipment  you  are  buying 
interoperates .  Ask  specifically  about  version  numbers  and 
system  configuration,  not  just  the  X.400  system. 

•  Watch  out  for  updates  and  upgrades.  Test  everything 
before  you  install.  You  need  to  test  compatibility  all 
over  again  if  one  component  changes. 

•  Backbone  designs  are  usually  more  efficient  to  manage  than 
point-to-point  gateways,  as  they  have  fewer  interdependent 
components  and  less  equipment,  reducing  maintenance 
requirements . 

•  Evaluate  the  administrative  interface  and  functionality  of 
the  systems.  it's  a  woefully  underappreciated  fact  that 
an  easy-to-use  interface  can  save  valuable  time  and  make 
troubleshooting  easier  by  orders  of  magnitude. 


C.   E-MAIL  PRODUCT  REVIEW 

This  section  provides  a  snapshot  of  today's  top-three  E- 

Mail  products  and  the  X.400  services  they  provide.   The  Local 

Area  Network  (LAN)  E-Mail  market  is  overwhelmingly  dominated 

by  Lotus   Development   Corp . ' s   cc:Mail,   Microsoft   Corp . ' s 

Microsoft  Mail  and  WordPerfect  Corp.'s  WordPerfect  Office,  in 

that  order.   In  1993,  the  LAN  E-Mail  market  was  estimated  at 

$224  million  in  worldwide  revenues  according  to  International 

Data  Corp.,  a  market  researcher  in  Framingham,  Mass..   The 

trend  is  likely  to  continue  as  companies  downsize  to  LAN-based 

packages  from  mainframe-based  solutions  and  software  suites 

become  more  entrenched. 

"The  market  used  to  be  very  fragmented,  with  the  leading 
vendors  taking  90  percent  of  the  market,"  said  Matt  Cain, 
program  director  of  the  workgroup  computing  for  Meta 
Group,  a  consultancy  in  Westport,  Conn..   He  continued, 
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"Lotus  and  Microsoft  by  the  end  of  1993  will  have  half  of 
the  worldwide  installed  base  of  E-Mail  users,  and  those 
two  companies  account  for  60  percent  of  all  new  sales." 
(Rooney,  1993,  p. 116) 

According  to  Dave  Whitten,  program  director  of  office 
information  systems  for  Gartner  Group  Inc.,  a  market 
researcher  in  Stamford,  Conn.,  WordPerfect  had  only  11.6 
percent  of  the  LAN  E-Mail  market  at  the  end  of  1992.  In 
September  of  1993,  it  had  14.6  percent.  (Rooney,  1993,  p. 116) 

The  main  features  of  these  packages  as  well  as  X.400 
services  provided  are  listed  below: 

Lotus  Development  Corp.'s  cc:Mail 

•  General  Description:  cc:Mail  is  a  "family"  of  more  than  20 
LAN-based  products  that  provide  high-end,  multimedia  E- 
Mail  capabilities  to  users  of  all  operating  systems  listed 
below.  It  provides  connectivity  with  LAN,  mini-  and 
mainframe-based  E-Mail  systems  and  can  connect  to  public 
E-Mail  services  and  fax  machines  worldwide. 

•  Operating  Systems  cc:Mail  Products  Support:  DOS:  cc:Mail 
for  MS-DOS  4.01  runs  under  all  versions  of  DR,  PC  or  MS- 
Dos  3.1  or  later;  OS/2:  cc:Mail  for  OS/2  3.2  runs  under 
OS/2  l.X  and  2.0  cc:Mail  for  DOS  and  Windows  can  run  under 
OS/2  2.0;  Windows:  cc:Mail  for  Windows  1.11  supports 
Windows  3.0  and  3.1;  Macintosh:  cc:Mail  for  Macintosh  2.0 
runs  on  System  6.  Ox,  System  7,  and  A/UX  2.0;  Unix:  cc:Mail 
for  Unix  1.0  runs  on  Sun  SPARC  stations  with  the  OPENLOOK 
user  interface.  (Lotus,  1993,  p. 5) 

•  Gateway  Connectivity:  Gateway  products  (meaning  that  you 
have  to  buy  them  in  addition  to  cc:Mail  package)  from 
cc:Mail  and  leading  third  party  vendors  to  allow 
connectivity  with  major  E-Mail  systems  in  the  world. 
Cc:Mail  offers  gateways  to  Novell  MHS,  IBM  PROFS, 
SMTP/UNIX/uucp,  3COM,  MCI,  AT&T,  Sprint.  In  order  to 
obtain  X.400  connectivity,  you  must  obtain  other  vendors' 
gateway  support  (such  as  Retix  or  Soft-Switch).  (Lotus, 
1994,  p. 7) 

•  Standards  Support:  cc:Mail 's  standards  support  includes 
the  following  data  communications  standards:  Novell's  MHS, 
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X.400,  SMTP  and  X.25  via  the  Lotus  Communications  Server 
and/or  cc:Mail  gateway  products.  (Lotus,  1994,  p. 4) 


Microsoft  Corp.'s  Microsoft  Mail 

•  General  Description:  Microsoft  Corp.  provides  a  multi- 
media capable  (Basically,  this  translates  to  sound  and 
graphics  files  being  incorporated  into  the  mail  file)  LAN- 
based  E-Mail  product.  It  provides  connectivity  with  LAN, 
mini-  and  mainframe-based  E-Mail  systems  and  can  connect 
to  public  E-Mail  services  and  fax  machines  worldwide.  It 
supports  users  on  the  following  operating  systems: 

•  Operating  Systems  Microsoft  Mail  Products  Support:  DOS: 
Microsoft  Mail  for  MS-DOS  runs  under  all  versions  of  MS- 
Dos  3 . 1  or  later;  OS/2:  Microsoft  Mail  for  OS/2  runs  under 
OS/2  1.2  or  later;  Windows:  Microsoft  Mail  for  Windows 
supports  Windows  3.0a  or  later;  Macintosh:  Microsoft  Mail 
for  Macintosh  runs  on  System  6.0.3  or  later;  Unix: 
Microsoft  Mail  does  directly  support  unix  at  this  time. 

(Microsoft,  1994,  p. 4) 

•  Gateway     Connectivity:     Gateway  products  from  Microsoft 
(meaning  that  you  have  to  buy  them  in  addition  to  the 

Microsoft  Mail  package)  for  connectivity  with  major  E-Mail 
systems  around  the  world  include:  Microsoft  Mail  Gateways 
to  IBM,  PROFS  and  Office  Version,  X.400,  Fax,  SMTP,  MHS, 
MCI  Mail,  3Com  3+Mail,  and  Microsoft  Message  Service  for 
IBM  SNADS.  (Microsoft,  1994,  p. 8) 

•  Standards  Support:  Microsoft  boasts  that  it's  Mail  and 
gateway  package  is  the  only  single,  complete  solution 
available  today  for  high-quality  connectivity  between  a 
LAN-based  mail  solution  and  international  standard  X.400 
systems.  This  is  no  longer  true  since  WordPerfect 
Corporation  launched  its  own  X.400  gateway  product  in 
January  1994.  Additional  data  communications  standards 
support  include:  Novell's  MHS,  SMTP  and  X.2  5  via  the 
Microsoft  Mail  Server  and/or  Microsoft  Mail  gateway 
products.  (Microsoft,  1994,  pp.  8  and  9) 


WordPerfect  Corp.'s  WordPerfect  Office  4.0 

•  General  Description:  WordPerfect  Office  4.0  is  an  office 
automation  product  which  includes  E-Mail  as  part  of  its 
functionality.  Specifically,  the  product  supports  group 
calendaring  and  scheduling,  task  management  (who  told  whom 
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to  do  what),  workflow  management  (ordered  distribution), 
message  and  outbox  management  (status  of  messages  sent), 
system  administration  and  gateway  support  management. 
(WordPerfect,  1994,  pp.  1-2) 

•  Operating    Systems    WordPerfect     Office    Products    Support: 

WordPerfect  Office  4.0  supports  PC  users  in  the  DOS  3 . 0  or 

higher  environment,  the  Windows  3 . 1  or  DOS  for  Windows  3.1 

or   higher,    and   Macintosh   System   7   or   higher. 

(WordPerfect,  1994,  p. 3) 

•  Gateway  Connectivity :  The  following  WordPerfect  gateways 
are  available  separately  from  the  WordPerfect  Office  4.0 
product:  PROFS  and  Office  Vision/VM,  SNADS,  cc:Mail, 
Novell  MHS,  SMTP,  X.400,  MCI  Mail  and  AT&T  EasyLink.  With 
respect  to  X.400,  the  WP  X.400  gateway  allows  the  X.400 
system  to  function  as  a  long  distance  message  transport 
service  to  connect  with  other  external  WP  Office  system 
users.  The  gateway  operates  on  an  OS/2  version  2.0  or 
higher  environment.  (WordPerfect,  1994,  pp.  2,7-8) 


D.   E-MAIL  IN  DOD 

As  part  of  the  Administration's  "reinventing  government 
initiative"  led  by  Vice  President  Al  Gore,  E-Mail  is  playing 
an  increasingly  important  role  in  the  Federal  Government.  In 
August  of  1993,  an  interagency  task  force  was  created  to 
design  a  strategy  for  providing  interconnectivity  among 
agencies.  Its  charter  is  to  develop  an  infrastructure  for  E- 
Mail  using  X.400/X.500  standards.   (Smith,  1993,  p. 68) 

The  next  chapter  discusses  the  Department  of  Defense's 
role  in  this  requirement  with  the  Defense  Message  System  (DMS) 
Program.  One  of  the  preliminary  requirements  was  to 
identify  the  major  products  and  quantities3  in  use  by  DoD 


3These  numbers  are  based  on  a  DoD-wide  survey  conducted  in 
1992  by  DISA.  As  of  March  1994,  the  current  quantities  in  use  of 
these  E-Mail  packages  have  not  been  identified.   (Dittmer,  1994) 
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users  that  are  desired  for  upgrade  to  DMS  compliance.  This 
enabled  specifications  to  be  written  for  X.400/X.500 
compatibility  and  connectivity.  These  packages  are  identified 
in  Table  3-1.  Not  surprisingly,  the  worldwide  E-Mail  leaders 
are  included.  (DoAF  DMS  RFP,  1993,  p.A13-l) 

TABLE  3-1:  E-MAIL  PACKAGES  USED  IN  DOD  AS  OF  JULY,  1992 

E-mail  Vendor        E-mail  Product/*  Components 

Lotus  Development  Corp.  cc :Mail/85 , 730 

Microsoft  Corp.  Microsoft  Mail/62,000 

Beyond  Inc.  Beyond  Mail/28,000 

Banyan  Systems  Inc.  Banyan  Mail /27,  750 

Da  Vinci  Systems  Corp.  Da  Vinci  eMail/16,000 

Word  Perfect  Corp.  WordPerfect  Office  /6,000 

LJL  Enterprises,  Inc.  PC  MAX  E-mail/100,000 


Can  these  disparate  E-Mail  packages  be  incorporated  in 
DMS?  If  ZD  Labs  test  results  are  any  indication,  the  answer 
will  be  "yes"  with  some  compromises.  Chapter  IV  has  excerpts 
from  DoD's  draft  Request  for  Proposal  (RFP)  for  the  DMS  that 
was  released  to  industry  for  comments  September  1993. 
Overall,  the  chapter  illustrates  the  basic  plan  for  an 
X.400/X.500  enterprise,  or  DoD-wide  messaging  infrastructure 
with  specific  focus  on  the  E-Mail  requirements. 
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IV.    X.400/X.500  AND  THE  DEFENSE  MESSAGE  SYSTEM 

A.   BACKGROUND  OF  DMS 

In  January,  1988,  the  Assistant  Secretary  of  Defense 
(ASD) /  Command,  Control,  Communications  and  Intelligence  (C3I) 
formed  a  multi-Service  and  agency  Defense  Message  System 
Working  Group  (DMSWG)  to  assess  the  future  of  DoD's  messaging 
system.  The  primary  objectives  were  to:  first,  define  the 
baseline  DMS;  second,  reliably  estimate  its  cost  to  the  DoD; 
and  third,  formulate  a  target  DMS  architecture  based  on 
achievable  technology.  The  DMSWG  developed  a  Target 
Architecture  and  Implementation  Strategy  (TAIS)  by  using 
inputs  from  Government  and  industry,  and  by  capitalizing  on 
advances  in  technology  and  standards.  The  conceptual  TAIS  was 
approved  by  the  Defense  Acquisition  Board  in  May  1988;  and  the 
Under  Secretary  of  Defense  for  Acquisition  issued  DMS  Program 
Guidance  in  August  1988.  The  Program  Guidance  provided 
approval  of  the  target  architecture,  the  phased  implementation 
strategy,  the  test  and  evaluation  and  the  management 
structure.  Additionally,  it  tasked  the  Defense  Communication 
Agency  (now  called  the  Defense  Information  Services  Agency 
[DISA] )  with  responsibility  of  overall  DMS  coordination,  and 
provided   initial   tasking   to   the   services   and   agencies 
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necessary  to  begin  execution  of  the  DMS  implementation 
strategy . 

In  October  1988,  the  DMS  management  structure  was  fully 
activated.  By  February  1989,  the  Joint  Staff  implemented  the 
validated  Multi-command  Required  Operational  Capability  for 
the  DMS  (MROC-DMS) .  Finally,  in  accordance  with  the  interim 
policy  guidance,  transition  planning  is  now  underway  by  all 
services  and  agencies.  (TAIS,  1993,  p. 1-1) 

As  mentioned,  one  of  the  first  tasks  for  the  DMSWG  was  to 
identify  a  DMS  "baseline"  to  serve  as  the  reference  against 
which  the  future  cost,  manpower  and  performance  during  the 
evolution  to  the  target  architecture  would  be  measured.  It  is 
important  to  note  that  this  baseline  is  "frozen"  in  time,  and 
will  not  change  over  the  DMS  planning  period. 

B.   DMS  BASELINE  COMPONENTS 

The  primary  components  of  the  DMS  baseline  are  the 

Automatic  Digital  Network   (AUTODIN)   system  which  provides 

organizational   messaging   between   organizational   elements 

(usually  chain  of  command)  and  electronic  mail  on  the  DoD 

Internet  (called  the  Defense  Data  Network  or  DDN)  providing 

messaging  capability  between  individuals  (staff  personnel). 

The  components  of  the  AUTODIN  are:  (TAIS,  1993,  pp.  2-1,2-3) 

•  AUTODIN    Switching    Centers     (ASCs)     -  The  ASCs,  of  which 
there  are  15  operational  ones  throughc  lut  the  world, 
perform  store-and-forward  message  switching  functions, 
some  message  validation  functions,  format  conversion  and 
some  specialized  routing  functions. 
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•  Automated  Message  Processing  Exchanges  (AMPEs)  -  There  are 
over  100  AMPEs  worldwide  which  include  the  Navy's  Local 
Digital  Message  Exchange  (LDMX),  the  Army's  Automated 
Multi-Media  Exchange  (AMME) ,  the  Air  Force's  Automated 
Message  Processing  Exchange  (AFAMPE) ,  National  Security 
Agency's  STREAMLINER  and  Defense  Intelligence  Agency's 
Communication  Support  Processor  (CSP) .  The  AMPEs  provide 
concentrator  and  limited  switching  for  attached  terminals, 
plus  other  functions  such  as  conversion  of  destination 
names  (Plain  Language  Addresses  [PLAs])  into  internal 
AUTODIN  addresses  (called  Routing  Indicators  [RIs]). 

•  Telecommunication  Centers  (TCCs)  -  TCCs  are  the  principal 
entry  and  exit  points  for  AUTODIN  messages.  TCCs  contain 
administrative  message  centers  with  manual 
over-the-counter  operations,  a  variety  of  terminal 
equipment,  optical  character  readers  and  video  display 
terminals  to  enter  messages. 

•  Data  Processing  Installations  (DPIs)  The  message 
function  of  sending  and  receiving  data  rather  than 
narrative  messages  is  accomplished  by  the  interfaces 
between  AUTODIN  and  the  DPIs.  This  interface  can  either 
be  direct  into  an  ASC  or  indirect  via  an  AMPE . 

•  Automated  Message  Handling  Systems  (AMHSs)  -  Some  users  of 
the  DMS  baseline  have  implemented  AMHSs  which  assist  in 
the  automated  processing  of  messages.  This  may  include 
message  coordination  and  release,  storing,  sorting  and 
retrieving  messages,  and  electronic  mailbox  distribution 
schemes . 

•  Directories  (DIR)  -  DIRs  are  paper  documents  such  as  the 
Message  Address  Directory  (MAD)  containing  organization 
names  and  associated  PLAs  and  the  ACP  117  series  of 
publications  which  include  PLAs  with  assigned  Ris  for 
AUTODIN  recognition. 

The  baseline  architecture  is  represented  in  Figure  4-1. 

(TAIS,  1993,  p. 2-2) 


C.   DMS  REQUIREMENTS 

The  main  problem  with  the  DMS  baseline  is  one  of 
interoperability.  While  both  primary  components  provide 
messaging  service  to  DoD  users,  their  dis jointedness  prevents 
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Figure  4-1:  DMS  Baseline  Architecture 
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the  interoperability  required  to  allow  an  efficient  and 
effective  exchange  of  message  traffic  from  AUTODIN  to  DDN.  In 
order  to  solve  this  problem,  the  following  brief  requirements 
have  been  identified  for  DMS :  (TAIS,  1993,  pp. 1-4  to  1-6) 

•  Connectivity/Interoperability  -  Within  the  community  of 
users  identified  as  organizations  and  personnel  in  the 
DoD,  the  DMS  should  allow  a  user  to  communicate  with  any 
other  user  whether  fixed  or  mobile.  Additionally,  DMS 
must  support  interfaces  to  systems  of  other  government 
agencies,  allies,  tactical  and  defense  contractors. 
Connectivity  must  extend  from  writer  to  reader.  And,  it 
should  lead  DoD's  migration  to  international  standards  and 
protocols . 

•  Guaranteed  Delivery  and  Accountability  -  With  a  high 
degree  of  certainty,  DMS  must  deliver  a  message  to  the 
intended  recipient (s )  .  Prompt  notification  of  non- 
delivery to  the  sender  must  occur  if  the  system  cannot 
deliver  a  message. 

•  Timely  delivery  -  The  DMS  must  recognize  messages  that 
require  preferential  handling.  It  must  also  dynamically 
adjust  to  changing  traffic  loads  and  conditions  during 
peacetime,  conflict  and  war.  Delivery  time  will  be  a 
function  of  message  precedence  and  system  stress  level. 

•  Confidentiality/Security  -  The  DMS  must  process  and 
protect  all  levels  and  compartments  of  classification  of 
message  traffic.  It  must  maintain  separation  of  messages 
within  user  communities  to  ensure  confidentiality  or  the 
preclusion  of  access  to  or  release  of  information  to 
unauthorized  recipients.  Security  will  also  be  based  on 
requirement  for  authentication  and  integrity  as  well  as 
confidentiality . 

•  Sender  Authentication  -  Information  marked  as  having 
originated  at  a  given  source  must  be  unambiguously 
verified  by  the  DMS.  For  organizational  traffic,  a 
message  must  be  approved  by  competent  authority  before 
transmission. 

•  Integrity  -  Information  content  received  must  be  the  same 
as  that  sent.  If  authorized  by  the  writer,  DMS  may  make 
necessary  format  changes  to  account  for  differences 
between  the  component  systems  serving  the  writer  and  the 
reader. 
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•  Survivability  -  The  DMS  must  not  degrade  the  survivability 
of  the  systems  interfaced  to  it .  Methods  such  as 
redundancy,  proliferation  of  system  assets  and  distributed 
processing  may  be  employed  to  achieve  survivability. 

•  Availability/Reliability  -  The  DMS  must  provide  message 
service  to  users  on  a  continuous  basis.  Availability  will 
be  achieved  through  a  combination  of  reliable  and 
maintainable  components,  thoroughly  tested  software,  and 
necessary  operational  procedures. 

•  Ease  of  Use  -  Use  of  the  DMS  should  not  require  extensive 
training  or  the  knowledge  of  a  communications  specialist. 

•  Identification  of  Recipients  -  The  sender  must  be  able  to 
unambiguously  identify  to  the  DMS  the  intended 
recipient (s)  .  The  necessary  directories  and  their 
authenticity  are  part  of  the  DMS. 

•  Message  Preparation  Support  -  User-friendly  preparation  of 
messages  for  transmission  must  be  provided  by  the  DMS 

(i.e.,  U.S.  Message  Tex:  Format  assistance) 

•  Storage  and  Retrieval  Support  -  The  DMS  must  promote 
storage  of  messages  after  delivery  to  allow  retrieval  for 
such  purposes  as  readdressal,  retransmission  and  automated 
handling  functions  with  the  capability  of  incorporating 
segments  into  future  messages . 

•  Distribution,  Determination  and  Delivery  -  For 
organizational  message  traffic,  the  DMS  must  determine  the 
destination ( s)  of  each  message  (in  addition  to  the 
addresses (s)  specified  by  the  originator)  and  ensure 
delivery  in  accordance  with  requirements  of  the  recipient 
organization.  For  individual  message  traffic,  delivery  of 
each  message  to  the  individual (s )  specified  by  the 
originator  must  be  accomplished. 


D.   DMS  TARGET  ARCHITECTURE  &  IMPLEMENTATION  STRATEGY 

Summarized  in  Figure  4-2,  the  Target  Architecture  is  shown 
in  terms  of  the  primary  functional  elements  required  to 
provide  the  DMS  messaging  services  (TAIS,  1993,  p. 3-3).  The 
message  transfer  agents  (MTAs),  message  stores  (MSs),  user 
agents  (Uas) ,  and  organizational  user  agents  (OAUs)  accomplish 
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the  X.400  message  handling  functions  that  were  described  in 
Chapter  II.  A  hierarchical  distribution  directory  (DIR)  along 
with  directory  user  agents  (DUAs)  provide  the  DMS  X.500 
directory  services.  Security  services  are  provided  using  the 
Secure  Data  Network  System  Message  Security  Protocol  ( SDNS 
MSP)  and  other  various  lower  layer  protection  mechanisms.  An 
MSP  gateway  provides  the  necessary  interfaces  with  non-MSP  DMS 
users  in  the  NATO,  allied,  tactical,  civil,  commercial  and 
research  communities.  These  various  functions  are  performed 
within  physical  components  which  are  distributed 
geographically  and  organizationally,  but  act  in  harmony  to 
provide  the  DMS  services.  (TAIS,  1993,  p. 3-2) 

The  implementation  strategy  involves  three  phases  spanning 
the  years  1989  to  2008.  Figure  4-3  illustrates  this  timeline 
and  the  corresponding  objectives  of  each  phase  (TAIS,  1993, 
p. 4-2)  . 

1 .   Phase  1 

The  first  phase  emphasizes  automation  of  existing  TCC 
functions  and  extension  of  messaging  services  to  users. 
Basically,  there  will  be  improvements  in  AUTODIN's  directory, 
an  AUTODIN-to-DDN  interface  capability,  and  a  migration  of  DDN 
E-mail  from  SMTP  to  X.400.  services  and  agencies  will  have  the 
opportunity  to  phase  out  their  resource-intensive  baselevel 
TCCs,  migrate  AUTODIN  data' pattern  message  traffic  to  the  DDN, 
begin   the   organizational   transition   and   prepare   their 
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Figure  4-3:   DMS  Implementation  Strategy 
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organizational   and   individual   messaging   communities   for 
evolution  to  the  next  phase.  (TAIS,  1993,  p. 4-1) 

2.  Phase  2 

The  second  phase  will  produce  the  most  obvious 
architectural  changes  and  improvements.  It  begins  with  the 
initial  operational  capability  for  X.400/X.500  individual  and 
organizational  messaging  with  SDNS  MSP  protection.  The 
baseline  procedures ,  protocols ,  formats ,  policies  and 
standards  will  begin  the  migration  to  the  target  architecture. 
TCC  functions  and  responsibilities  will  be  shifted  to  OAU 
workstation  applications,  thus  accelerating  TCC  phase-outs. 
With  the  simultaneous  deployment  of  X.400  MTAs ,  X.500 
directory  services,  DMS  management  control  capabilities  and 
SDNS  security  protection,  an  integrated  X.400/X.500  SDNS  DMS 
organizational  and  individual  messaging  system  will  be  rooted 
and  maturing.  AMPEs  and  ASCs  will  be  phased  out.  (TAIS, 
1993,  p. 4-3) 

3 .  Phase  3 

The  third  phase  commences  when  the  last  ASC  is  closed. 
The  primary  emphasis  during  this  phases  is  the  maturation  of 
the  X . 400/X. 500/SDNS  organizational  and  individual  messaging 
system  and  achievement  of  the  target  architecture.  The  local 
and  long  haul  portions  of  the  DoD  Internet  will  also  mature 
and  the  DCS  backbone  will  have  evolved  to  a  fully  integrated 
Defense  Information  System  Network  (DISN) .  (TAIS,  1993,  p. 4-3) 
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E.   X. 400 /X. 500  AND  THE  DMS 

1.   Baseline  E-mail  on  the  DoD  Internet 

In  1982,  the  Defense  Data  Network  (DDN)  was 
established.  It  is  a  set  of  world-wide  networks  that  are 
based  on  technology  developed  by  the  Defense  Advanced  Research 
Projects  Agency  (DARPA)  as  the  ARPANET  in  the  early  1970 's. 
One  of  the  primary  uses  of  the  ARPANET  was  to  provide  E-mail 
to  the  DoD  research  community.  This  capacity  was  extended  to 
other  operational  users  on  the  DDN.  The  protocols  that  were 
in  use  in  the  early  eighties  were  expanded  for  connection  of 
baseline  transmission  facilities  to  wide-area  networks. 
Collectively,  the  baselevel  and  long-haul  transmission 
facilities  are  termed  the  DoD  Internet;  and,  the  expanded 
message  transfer  protocols  for  the  Internet  are  Transfer 
Control  Protocol  (TCP) /Internet  Protocol  (IP)  and  the  Simple 
Mail  Transfer  Protocol  (SMTP).  The  principal  components  of 
the  E-mail  system  are  host  computers  supporting  E-mail,  user 
terminals,  on-line  directories,  and  the  DoD  Internet.  (TAIS, 
1993,  p. 2-8)   Specifically, 

•  E-mail  hosts  are  computers  that  have  (1)  installed  an 
application  program  which  interfaces  with  users  on 
terminals  to  compose,  send  and  receive  messages;  and  (2) 
implemented  the  Simple  Mail  Transfer  Protocol  (SMTP)  as 
well  as  the  necessary  underlying  protocols  which  allow 
them  to  send  and  receive  mail  from  other  E-mail  hosts 
(which   may   include   proprietary   E-mail   protocols). 

Additionally,  storage  is  provided  by  the  host  computers  to 
keep  received  mail  until  the  users  have  read  it. 

•  User  terminals   can  be  defined  as  any  computer  terminal  or 
PC  with  terminal  emulation  software. 
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•  Directories   are  exceptionally  important  since  they  are  the 
phone  books  of  E-mail.  The  DDN  Network  Information  Center 

(NIC)  computer  contains  a  directory  of  over  50,000  E-mail 
users.  It  contains  the  user's  name  and  mailbox  address 
consisting  of  an  identifier  for  the  user  and  one  for  the 
E-mail  host.  A  second  directory  containing  host  names  and 
corresponding  Internet  addresses  is  also  located  at  the 
NIC  and  is  currently  being  distributed  throughout  the  DoD 
Internet . 

•  The  DoD  Internet  is  included  for  completeness  since  it  is 
the  avenue  for  E-mail.  The  DoD  baseline  Internet  has  three 
components.  The  first  component  is  the  classified  DDN 
which  is  a  set  of  physically,  procedurally,  and 
cryptographically  secured  packet  switched  segments.  These 
segments  are  referred  to  as  DSNET1 ,  DSNET2  and  DSNET3 . 
The  second  component  is  the  unclassified  DDN  which  is  the 
packet  switched  segment  providing  the  backbone  for 
unclassified  E-mail.  The  third  component  is  the  Baselevel 
Transmission  Facilities  which  have  traditionally  supported 
switched  voice  circuits,  dedicated  point-to-point 
communications  and  simple  star  networks.  MILNET  is 
usually  considered  part  of  the  DDN. 

(TAIS,  1993,  pp. 2-8  to  2-9) 

2.   Transition  to  X.400/X. 500-based  DMS 

For  DoD  services  and  agencies,  individual  messages  are 
carried  over  the  DDN  using  the  Internet's  Simple  Mail  Transfer 
Protocol  (SMTP) .  AUTODIN  is  used  to  exchange  organizational 
(both  classified  and  unclassified)  messages  in  DoD.  As  Figure 
4-4  illustrates,  DMS  will  convert  the  SMTP  individual  message 
transfer  world  into  an  X.400/X.500  combined  (individual  and 
organizational)  message  transfer  world.  The  DMS  Program  is 
relying  on  another  Program  called  the  Defense  Information 
System  Network  (DISN) ,  which  is  being  managed  concurrently 
with  DMS,  to  transition  (1)  packet  switching  and  sub-DSl 
transmission  for  today's  DDN  to  broadband  switching  and 
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transmission;  and  (2)   TCP/IP  (Internet)  network  layers  into 
the  OSI  Transport  network  layers.  (TAIS,  1993,  p.A-2) 

A  high-level  picture  of  what  DMS  is  trying  to  accomplish 
with  respect  to  X.400/X.500  and  a  message  handling  system  is 
illustrated  in  Figure  4-4. 
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Figure  4-4:  DMS  is  Responsible  for  the  Transition  of  a 
"SMTP  MHS"  to  an  "X.400  MHS" 
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3.   X.400  DMS  Gateways 

Figure  4-5  depicts  a  transitional  architecture  for 
Phase  I  of  the  DMS  (TAIS,  1993,  p.A-46)  .  The  primary 
importance  of  this  illustration  is  gateway  functionality.  The 
architecture  calls  for  gateway  connections  between  (1)  SMTP 
and  X.400  users,  (2)  DISN  and  the  global  Internet  and  (3) 
AUTODIN  and  the  MILNET  segment  of  DISN.  By  Phase  II,  the 
gateways  will  provide  the  following  AUTODIN- to -DISN  Interface 
(ADI)    and  connectivity  support:  [TAIS,  p.  A-45] 

•  AUTODIN-to-DISN  Message  Conversion.  This  conversion 
occurs  when  narrative  messages  are  written  by  AUTODIN 
writers  and  routed  to  DDN  E-mail  readers  by  means  of 
AUTODIN  Plain  Language  Addresses  (PLAs) .  They  are  routed 
to  the  ADI  and  converted  to  DDN  E-Mail  addresses  (i.e., 
SMTP  and/or  X.400) 

•  DDN- to -AUTODIN  Message  Conversion.  Basically,  an  E-mail 
user  may  generate  an  E-mail  message  and  transmit  it  via 
SMTP  or  X.400  to  the  ADI,  with  AUTODIN  PLAs  included  as 
part  of  the  address. 

It  is  important  to  note  that  DMS  specifications  call 

for  connectivity  for  both  the  Internet  and  OSI  until  DISN 

migration  is  complete.   Therefore,  gateways  between  SMTP  and 

X.400  will  be  commonplace.    Other  gateways  that  will  be 

required  for  E-Mail  connectivity  include:  [TAIS  A-48-56] 

•  Mail  Relay  Gateway  between  DISN  and  the  Global  Internet  is 
required  to  relay  SMTP  and  X.400  mail. 

•  Mult i -Function  Gateway  between  DISN  and  the  Global 
Internet  will  translate  between  SMTP  and  X.400 
"classified-capable"  users.  It  must  be  able  to  translate 
cryptographic  mechanisms  for  DoD  and  its  Allies. 
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Figure  4-5:   DMS  Gateway  Transitional  Architecture 
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•  DMS-to-Tactical  Gateways  are  required  to  include  an  X.400 
interface  with  the  tactical  and/or  mobile  users  in  order 
to  bring  them  into  the  DMS  E-Mail  community.4 

•  Guard  Gateway  is  required  to  ensure  that  classified  data 
on  DISNET  is  not  passed  inadvertently  or  intentionally  to 
users  on  the  MILNET.  At  the  same  time,  it  must  allow 
unclassified-but-sensitive  traffic  to  pass  between  the 
networks . 

•  GateGuard  is  a  generic,  Navy-developed  gateway  to  the 
commercially  available  Automated  Information  Systems 
(AISs)   or  the  Office  Automation  Systems   (OASs)   with 

proprietary  and  SMTP  E-Mail.  It  is  used  for  the  electronic 
delivery  of  AUTODIN  messages  from  the  user's  desktop 
terminal . 

The  above  Phase  1  gateways  are  transitional  devices 

needed  at  the  application  layers  (layers  6&7  of  the  7-layer 

OSI  network  model)  to  support  the  DMS  message  environment. 

Table  4-1  depicts  the  DMS  transitional  gateway  requirements 

for  a  DMS  user  that  is  capable  of  sending  and  receiving 

AUTODIN,  DDN  E-Mail  (SMTP),  or  X.400  messages.   This  user  may 

or  may  not  have  the  Preliminary  Message  Security  Protocols 

(PMSPs)  requirement  for  transmitting  classified  messages.   It 

is  important  to  note  that  the  Message  Security  Protocol  (MSP) 

conversion   capability   will   be   incorporated   with   the 

availability  of  MSP  at  the  start  of  Phase  II.   Phase  II  and 


4The  tactical  gateways  include:  (1)  the  Tactical  Packet- 
Switched  Network-AUTODIN  Gateway  which  will  bridge  the  Army's 
Tactical  Packet-switched  Network  (TPN)  with  AUTODIN;  (2)  the 
Tactical  Packet-switched  Network-Defense  Data  Network  Gateway  which 
the  Army  requires  to  bridge  its  TPN  with  the  classified  network 
portion  of  the  DDN;  (3)  the  Naval  Communications  Processing  and 
Routing  System  II  Gateway  which  the  Navy  requires  for  a  tactical 
gateway  link  to  AUTODIN  allowing  interoperation  with  the  X.400 
messaging  environment;  and,  (4)  the  Navy  X.400  Fleet  Gateway  used 
specifically  for  its  interface  with  X.400  shipboard 
implementations.  [TAIS,  pp.A-50-51] 
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TABLE  4-1:    DMS  TRANSITIONAL  GATEWAY  REQUIREMENTS  DURING 
PHASE  I  FOR  A  DMS  USER 
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Ill  gateway  implementations  and  concept  of  operations  have  not 
been  published  at  this  time.  [TAIS,  pp.  86-88] 

Although  not  as  large-scale  as  the  DoD's  DMS,  the  next 
chapter  discusses  the  i  tive  X.400/X.500  implementation  for 

000  users  at  Wal-Mart  Stores  Inc.   that   is  currently 

?rway . 
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V.   WAL-MART  STORES  INC.  ENTERPRISE  MESSAGING  SYSTEM 

A.   BASIC  HISTORY 

Wal-Mart  Stores,  Inc.  is  a  large  retailing  business 
currently  dispersed  across  approximately  2,000  locations,  both 
foreign  and  domestic.  Each  employee  of  Wal-Mart,  whether  in 
a  store,  the  corporate  complex,  one  of  Sam's  Clubs,  or  a 
distribution  center,  is  referred  to  as  an  "associate"  of  which 
there  are  currently  more  than  350,000.  Wal-Mart  has  achieved 
its  current  success  because  of  a  history  of  "never  being 
satisfied  with  the  way  things  are.  The  company  is  a  visionary 
one  which  "learns  from  and  cherishes  its  past,  but  does  not 
live  in  it."  The  following  momentous  highlights  of  one  of  the 
greatest  retail  companies  in  U.S.  history  illustrate  their 
success:   (Wal-Mart,  1993) 

•  1950  Sam  Walton  founded  Walton' s  5&10  in  Bentonville, 
Arkansas.  Rob  Walton,  the  current  Chairman  of  Wal-Mart 
Stores  Inc.  reflects  on  his  father's  early  business,  "When 
my  brothers  and  sisters  were  growing  up,  we  always  worked 
in  dad's  stores ...  sweeping  floors,  carrying  boxes,  even 
running  the  ice  cream  machine.  I  remember  feeling  that 
all  the  associates  in  the  store  were  part  of  the  family, 
always  willing  to  help  each  other..." 

•  1963  First  Wal-Mart  store  in  Rogers,  Arkansas  solidified 
the  concept  that  large  discount  operations  can  succeed  in 
small  towns. 

•  1970  Wal-Mart  becomes  a  public  company,  entering  the 
world  of  Wall  Street.  The  32  Wal-Mart  stores  had  $31 
million  in  sales. 

•  1972   The  Wal-Mart  profit  sharing  plan  was  instituted. 
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•  1980  Over  300  Wal-Mart  operated  facilities  brought  in 
sales  of  $1.2  billion.  Sam's  Clubs  and  Supercenters 
became  permanent  divisions  of  the  company. 

•  1992  Mr  Sam  Walton  received  the  Presidential  Medal  of 
Freedom  shortly  before  his  death. 

•  1993  Wal-Mart  is  the  largest  retailer  in  the  world, 
operating  1957  general  merchandise  discount  stores,  163 
Sam's  wholesale  clubs  and  68  Supercenter  stores  which 
combine  food  and  general  merchandise  under  one  roof.  Wal- 
Mart's  revenue  reached  $67.3  billion  in  1993  (Merrill, 
1994,  p.  3)  .  The  company  is  poised  to  explode  into  the 
international  market  and  transplant  the  Wal-Mart  way  of 
doing  business:  customer  service,  great  values  and  respect 
for  each  other,  to  other  countries  (Wal-Mart,  1993). 

This  preparation  for  the  international  market  requires 

effective  communications  between  the  associates,  the  vendor 

partners,  and  the  purchasing  agents.   The  CCITT  X.400/X.500 

family  of  message  transfer  standards  will  support  Wal-Mart  in 

achieving  this  worldwide  messaging  enterprise  system. 

B.   BACKGROUND  OF  WAL-MART  MESSAGING  SYSTEM 

Wal-Mart's  communications  services  in  the  past  have 
included  basic  telephone  services,  U.S.  and  Wal-Mart  postal 
services,  and  session-oriented  computer  connections. 
Electronic  messaging  systems  are  currently  provided  through 
the  PROFS  system  and  the  Wal-Mart  store  message  system.  These 
systems  have  limited  capabilities  such  that  the  company  has 
basically  outgrown  them.  The  desired  E-Mail  system  is  defined 
as  a  " store-and-forward  transport  for  electronic  objects  to 
include  text,  documents,  forms,  spread  sheets,  graphics, 
images  and  even  digitized  voice."   The  transport  of  these 
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objects  can  occur  across  heterogenous  computers,  LANs,  and  WAN 
protocol  environments. 

C.   E-MAIL  REQUIREMENTS  OF  WAL-MART 

1.   Identification  of  Wal-Mart's  MHS  Platform  And  UAs 

Wal-Mart  currently  has  an  Ethernet-based  X.400  E-Mail 
backbone  which  overlays  on  the  internal  computer  networks  with 
gateways  to  the  public  data  networks.  There  are  approximately 
1,000  users  with  X.400  E-Mail  capabilities  and  3,000  or  so 
users  of  IBM's  mainframe  host  environment,  PROFS,  which  has 
provided  most  of  the  electronic  messaging  functionality  for 
the  company.   Wal-Mart  has  identified  the  following  UAs: 

•  Direct -Connect  Synchronous  Terminal .  The  hardware  platform 
for  this  UA  is  a  synchronous  terminal  directly  connected 
via  a  327x  cluster-controller  to  the  mainframe.  The  Mail 
option  is  selected  from  a  menu  and  the  interface  is 
limited  to  text. 

•  PC  with  Windows  and  LAN.  Primarily  a  user  within  the 
General  Office,  this  hardware  platform  is  a  386/486  PC 
with  LAN  connection  and  an  operating  stack  of  DOS,  Windows 
and  Attachmate  for  3270  connectivity.  These  users  are 
currently  either  using  X.400  E-Mail  or  are  still  using  IBM 
PROFS  via  3270  emulation. 

•  PC  with  DOS  and  LAN.  This  is  the  same  type  of  user  as 
above  with  DOS  as  the  only  element  of  the  operating  stack. 
Some  of  the  foreign  offices  and  agents  fall  into  this 
category.  They  communicate  by  asynchronous  modems  using 
a  proprietary  telex-type  communication  package  (i.e,  MCI 
Mail,  AT&T  EasyLink  or  Sprint  Mail) . 

•  PC  with  Windows  or  DOS  and  Modem.  Vendors,  smaller  foreign 
offices  and  managers  that  are  remote  have  a  modem  for 
direct  connection  to  the  Public  Switched  telephone  Network 
(PSN) . 

•  Mac  with  LAN.  Several  users  within  advertising  or  the 
general  office  have  Mac  workstations  that  use  QuickMail 
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and  are  not  connected  to  the  PROFS  messaging  system,  they 
will  be  provided  a  gateway  to  the  X.400  backbone. 

•  X-Term  and/or  UNIX  Client-Server.  These  users  are 
primarily  in  the  development  and  technical  support  areas 
of  the  general  office.  Elm  is  an  example  of  a  current  E- 
Mail  system  used  on  a  Unix  mailer  which  is  connected  to 
PROFS  through  address  translation  programs  on  the  host  and 
Fibronics  interface  connections  to  the  network. 

•  Wal-Mart  Stores.  The  stores  have  no  E-Mail  system,  only  a 
message  drop  which  literally  prints  out  text  on  printers 
at  the  stores.  Each  store  will  be  connected  to  the  X.400 
backbone  separately  by  implementing  local  mail  servers  by 
installing  software  on  the  In-Store  Processor  (ISP)  to 
provide  mail  storage  and  directory  service.  The  basic  idea 
for  the  stores  is  to  keep  E-Mail  uncomplicated,  so  the  UA 
will  be  "simplified"  (SUA)  with  only  basic  on-line  UA 
functions.  Installation  is  not  to  disrupt  any  of  the 
stores'  business  operations  since  they  are  truly  the 
backbone  of  the  company.  Typical  UAs  within  a  store  are 
the  various  types  of  managers  (i.e.,  Store,  Department, 
Customer-Service)  and  some  of  the  clerks. 

•  Distribution  Centers.  Currently  using  PROFS  through 
sessions  back  to  the  host,  they  will  migrate  to  local  mail 
servers  similar  to  the  stores. 

•  Sam's  Clubs.  These  are  wholesale  distribution  membership- 
only  clubs.  They  have  a  similar  computing  environment  to 
the  stores  and  distribution  centers. 

•  Vendor's  Enterprise  Network.  The  computer  systems, 
networks  and  mail  protocols  can  vary  greatly;  therefore, 
using  an  X.400  E-Mail  backbone  is  extremely  important 
since  many  proprietary  systems  provide  interoperability 
and/or  connectivity  with  X.400.  Wal-Mart  provides  MTAs  and 
UA  software  for  the  vendors  so  that  they  can  access  their 
enterprise  messaging  system. 

•  Fax.  Although  not  currently  connected,  the  basic  E-Mail 
idea  with  respect  to  fax  is  to  attach  a  scanned  fax  image 
to  a  message  to  either  a  recipients'  mailbox  or  their  fax 
machine.  Similarly,  fax  images  could  be  received  and 
reviewed  on  graphics  UAs  and  printed. 

Figure  5-1  illustrates  a  conceptual  version  of  Wal-Mart's 

Enterprise   E-Mail   System,   some   of   which   is   still   in 

conceptional  phases.   It  shows  the  connections  of  different 
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Figure  5-1:  Wal-Mart  Enterprise  Messaging  System  Areas. 
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Wal-Mart  divisions  across  the  WAN  that  need  to  be  connected  to 

the  X.400  backbone.   These  areas,  some  of  which  are  designated 

UAs  as  identified  above,  include: 

Foreign  Offices  (including  foreign  purchasing  agents) 

General  Office 

Buyers  Decision  Support  System, 

Retail  Link  and  EDI  (includes  the  vendors  that  use  these 

applications ) 

Stores 

Sam's  Clubs 

Distribution  Centers 

Subsidiaries  and  Business  Partners 

Remote  and/or  mobile  users 

Starting  in  the  upper  left-hand  corner,  the  IBM  mainframe 
system  with  PROFS  is  shown  which  is  connected  by  Ethernet  to 
the  backbone  by  an  SMTP-X.400  gateway.  Moving  clockwise,  the 
Enterprise  Messaging  System  provides  Internet  connectivity 
with  an  X.400 -SMTP  gateway  and  modem.  The  gateway  also 
ensures  firewall  protection  to  the  Internet.  In  the  upper 
right-hand  corner,  foreign  agents  are  connected  to  the  X.400 
backbone  with  Netware  connectivity  (which  locally  connects  the 
UA  to  the  MTA) .  However,  they  must  access  the  PSTN  (Public- 
Switched  Telephone  Network)  to  reach  one  of  the  MTAs  on  the 
backbone.  For  the  vendor  partners,  with  fewer  E-Mail  users, 
a  remote  user  agent  (RUA)  uses  FTP  (file  transfer  protocol) 
and  a  modem  connection  to  the  PSTN  to  the  X.400  MTA  backbone. 
Sam's  Clubs  and  the  Stores  obtain  X.400  backbone  connectivity 
through  their  existing  satellite  connectivity,  a  satellite 
Network  Hub  WAN,  and  the  MTAs  that  are  installed  in  the  In- 
Store  and  In-Club  Processors  (ISP  and  ICP,  respectively) .  The 
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SUAs  as  well  as  a  fully  functional  training  UA  (TUA)  provide 
all  UA  activities  to  the  associates.  The  distribution  centers 
and  the  foreign  partnership  areas  connect  to  the  backbone  via 
an  MTA  to  the  Wal-Mart  Network  by  dedicated  Tl  lines. 
Finally,  in  the  central  backbone  area,  the  bulk  of  the  X.400 
backbone  MTAs  are  illustrated  in  at  least  two-level  clusters. 
With  the  1984  version  of  the  NCR  StarPRO  Message  Central  400 
product,  the  maximum  number  of  adjacent  MTAs  allowed  is  255. 

2.  Wal-Mart's  UA  Requirements 

All  UAs  will  comply  with  X.400  (84).  The  primary 
commercial  E-Mail  package  that  will  be  utilized  is  Enterprise 
Mail  from  Enterprise  Solutions  for  the  following  platforms: 

•  Icon  Interface  in  MS  Windows  for  386/486  PC  with  LAN 

•  Icon  Interface  in  MS  Windows  for  386/486  PC  remote 

•  Character/Screen  based  for  Asynchronous  Terminals  with 
serial  connect 

•  Icon  interface  in  X-Windows  for  X-Terms . 

The  specific  X.400  specification  requirements  must  comply 
with  the  X.411  and  X.420  (Interpersonal  Messaging  System) 
portion  of  the  standard.  Refer  to  Chapter  II  for  a  more  in- 
depth  description  of  these  MHS  standards.  These  functions 
include:  Interpersonal  Messaging  Service,  Support  for  P2 ,  P3 
protocols ,  and  Originator/  Recipient  attributes  for 
addressing . 

3.  Identification  of  Wal-Mart's  MTAs 

Wal-Mart  has  identified  the  following  locations  and 
functions  for  their  enterprise's  MTAs: 
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•  General  Office  Complex.  This  MTA  will  function  as  the 
central  mail  server,  the  master  directory  server  and  will 
provide  gateways  externally.  Also  in  this  location,  there 
may  be  additional  MTAs  which  act  as  local  mail  servers  for 
divisions  within  the  complex  or  for  high  use  applications. 

•  Stores,  Clubs  and  Distribution  Centers.  Local  MTA 
applications  will  be  running  on  processors  within  these 
locations.  It  is  estimated  that  there  will  be  50  users  per 
store  and  100  per  distribution  center. 

•  Foreign  Offices.  Local  Unix  servers  will  require  the  MTA 
software  with  modem  access  and  a  connection  to  the  LAN  or 
a  direct  serial  connection  (provided  by  the  user) . 

•  Subsidiaries,  Business  Partners,  and  Large  Vendor 
Enterprises.  This  covers  any  medium-sized  enterprise  with 
whom  Wal-Mart  has  significant  E-Mail  and/or  EDI  traffic. 
This  system  would  be  an  MTA  and  provide  gateways  to  their 
internal  E-Mail  systems  (if  not  X.400). 

4.   Wal-Mart's  MTA  Requirements 

Since  Wal-Mart  is  creating  a  native   X.400  backbone, 
all  MTAs  must  meet  the  requirements  as  outlined  in  the  CCITT 
X.400  standards.   The  reference  product,  NCR  StarPro,  is  the 
Retix  Message  Server  for  Unix,  and  conforms  fully  to  the 
standard.   In  order  to  be  most  efficient  and  cost  effective, 
the  MTA  is  required  to  reside  on  an  Unix  operating  system 
which  (1)  takes  advantage  of  the  multi-tasking  capabilities 
and  (2)  shares  the  hardware  resources  with  other  applications, 
the  server  file  system  and  other  mail  gateways. 

Similar  to  the  UA  requirements,  the  MTA  should  provide 
full  support  of  the  PI,  P2  and  P3  protocols  (refer  to  Chapter 
II)  .  It  should  provide  reliable  message  store  (even  though 
Wal-Mart  is  implementing  the  1984  version)  and  data  transfer 
as  well  as  optimized  routing  and  tracking.    Although  MTA 
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customization  is  required  by  Wal-Mart  technicians,  NCR's 
StarPro  will  provide  administrative  tools  and  servers  to 
configure  X.400  mail  features  and  network  routing,  maintaining 
public  directories  and  distribution  lists,  delivery/non- 
delivery reports,  and  system  error  logging.  LAN  interfaces 
are  required  for  Novell  Netware,  TCP/IP,  and  the  public  data 
networks . 

Finally,  public  data  sharing  is  required  between  the 
main  mail  server's  MTA  and  any  other  MTA  within  the 
enterprise.  Administration  of  a  public  directory  for  an  MTA 
will  be  handled  locally.  Eventually,  directory 
synchronization  will  be  required  conforming  to  the  X.500 
standard. 

D.   WHY  X.400/X.500? 

Wal-Mart  wants  an  enterprise-wide  E-Mail  system  that  will 
enable  both  users  and  business  applications  to  communicate 
across  an  application  layer,  store-and-f orward  transport 
backbone.  The  types  of  business  applications  the  company 
wishes  to  use  on  the  enterprise-wide  E-Mail  service  include 
office  mail  for  the  home  office  complex  in  Arkansas,  vendor 
mail  services  for  Retail  Link  and  Electronic  Data  Interchange 
(EDI) ,  and  Buyers  Decision  Support  System  (BDSS) .  The  store- 
and-forward  aspect  of  their  E-Mail  plan  will  better  utilize 
the  bandwidth  in  the  company's  existing  LAN  and  satellite  WAN. 
Additionally,  X.400  is  the  sole  representation  of  the  open 
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systems  interconnection  electronic  messaging  standard,  yet 
another  attractive  feature. 

Overall,  this  E-Mail  system  must  be  an  enabling  technology 
that  will  evolve  with  the  industry  improvements  and  the 
demands  for  three  very  big  E-Mail  service  areas:  application 
interfaces,  administration,  and  directory  services.  Wal-Mart 
prefers  the  CCITT  X.400  family  of  standards  since  it 
functionally  meets  their  requirements.  This  X.400  enterprise 
system  will  provide  store-and-f orward  messaging  within  the 
Wal-Mart  enterprise. 

E.   X. 400 /X. 500  IMPLEMENTATION  STRATEGY 
1.   Methodology 

The  chronological  X.400  implementation  for  Wal-Mart's 
enterprise  system  started  with  the  General  Office  complex  and 
the  X.400  backbone.  Next,  vendors  were  connected.  X.400 
backbone  connection  for  the  international  areas  has  begun. 
One  is  currently  up  and  running;  another  is  on  the  way.  The 
stores  and  clubs  will  initially  be  connected  one  at  a  time. 
Then  groups  of  ten  stores  and/or  clubs  will  be  connected.  The 
rest  will  roll-out  quickly  in  larger  groups  since  the 
technicians  intend  to  have  the  set-up  and  configuration  of  the 
MTAs  totally  automated.  The  complete  installation  goal  is  end 
of  second  quarter  this  year,  or  June  1994. 
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2 .   Current  Status 

The  General  Office  complex  is  on-line  with  the  X.400 
backbone.  Currently  NCR's  StarPRO  is  running  well  (It  is  a 
Retix  Message  Server  for  Unix  clone) .  Additionally,  one 
application  is  successfully  running  at  this  time  on  the 
backbone . 

F.   LESSONS  LEARNED  THUS  FAR 

Although  the  X.400  backbone  installation  is  not  complete, 
Wal-Mart  technicians  have  learned  the  following  lessons  thus 
far.  First,  be  cautious  of  gateways  because  they  generate  a 
lot  of  administrative  work  such  as  directory  updates, 
synchronization,  error-checking  for  E-Mail  routing  as  well  as 
just  making  sure  the  mail  gets  through.  The  fewer  you  have, 
the  better. 

Second,  when  investigating  products,  check  into  the 
administrative  tools  that  are  provided  with  the  product.  The 
idea  is  to  NOT  require  very  many  people  to  be  highly  trained 
specialists . 

Third,  quality  of  the  directory  and  synchronization 
capabilities  are  also  key  features  to  look  for  when  reviewing 
X.400  products. 

Finally,  train  your  people  internally  before  the  actual 
implementation  with  the  focus  being  "what  the  program  can  do 
for  you" .  Ideally,  the  best  training  would  be  no  training 
since  that  would  imply  a  totally  seamless  integration. 
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G.   FUTURE  MESSAGING  REQUIREMENTS 

Wal-Mart  intends  to  upgrade  the  X.400  backbone  and 
messaging  infrastructure  with  the  X.400  (88)  version  upon 
completion  of  the  current  X.400  installation.  The  technical 
staff  is  currently  looking  into  the  message  store 
functionality  which  is  the  primary  new  feature  that  the  1988 
version  offers. 

Although  not  stated  explicitly  in  either  phone  interviews 
or  Wal-Mart  correspondence,  the  author  believes  Wal-Mart 
intends  to  overlay  as  many  application  programs  over  this 
store-and-f orward  architecture  that  they  can.  As  long  as  the 
application  program  interfaces  (APIs)  are  compatable  with  an 
X.400-based  architecture,  they  will  provide  the  broadest,  most 
efficient  (in  terms  of  moving  information  quickly  to  provide 
"better"  packages  for  "better"  business  decisions)  message 
transport  system. 
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VI.   CONCLUSIONS 

A.  BENEFITS   OF   AN   X.400   ENTERPRISE   ELECTRONIC   MESSAGING 
SYSTEM 

The  CCITT  X.400  (88)  family  of  standards  is  a  messaging 
transport  standard  that  facilitates  international  message 
exchange  between  subscribers  to  computer-based  store-and- 
forward  message  services.  Combined  with  an  appropriate 
network  architecture,  the  series  provides  a  complete  package 
for  transport  of  electronic  objects  which  may  include 
digitized  voice,  documents,  forms,  graphics,  images,  spread 
sheets  and  text.  Its  rival  protocol,  SMTP,  as  its  name 
implies,  is  simply  providing  mostly  textual  messaging 
capability.5  In  an  unprecedented  globally  competitive  market, 
industry  demands  an  electronic  mail  or  messaging  system  that 
will  transport  all  forms  of  data. 

B.  LESSONS  LEARNED  FROM  INDUSTRY 

Although  the  X.400  standard  in  one  form  or  another  has 
been  around  for  nearly  a  decade,  those  in  the  corporate  world 
that  have  implemented  the  standard  have  compiled  a  list  of 
lessons  learned.    Assembling  an  enterprise  messaging  system 


5Multiple  Internet  Mail  Extension  (MIME)  has  been  proposed  as 
an  extension  of  SMTP  to  allow  for  all  media  types  in  the  mail 
envelope . 
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does  require  a  working  knowledge  of  network  architecture  and 
transport  protocols,  as  well  as  a  full  understanding  of  X.400 
specifications.  Although  installation  time  may  be  enhanced 
with  the  very  best  available  technical  resources  (the  X.400 
vendors  themselves),  it  will  take  more  time  than  anticipated 
to  configure  each  MHS ' s  options.  Broad  knowledge  about 
client-server  operating  systems  and  mail  applications  is 
essential  during  installation.  As  mentioned  previously,  the 
following  additional  guidelines  may  improve  a  business 's  X.400 
implementation : 

•  Contract  with  vendors  or  reliable  third  party  service 
providers  to  help  with  initial  design,  planning, 
installation  and  configuration,  especially  if  you  don't 
have  specific  expertise  in  house.  This  will  pay  for  itself 
many  times  over. 

•  Train  support  people  so  you  build  expertise  in-house  and 
can  maintain  your  systems  in  the  long  run. 

•  Try  to  minimize  the  number  of  vendors  involved  in  the 
construction  of  your  system.  For  example,  it  may  be  a 
better  approach  to  purchase  all  gateways  from  one  vendor 
rather  than  individual  gateways  from  each  vendor.  Many 
companies  are  consolidating  their  E-Mail  systems  so  they 
only  need  to  support  three  or  four  rather  than  eight  or 
ten. 

•  If  you  purchase  equipment  from  more  than  one  vendor,  bring 
them  all  together  at  the  same  time  during  installation. 
In  addition,  make  sure  you  ask  about  interoperability 
testing  to  ensure  that  the  equipment  you  are  buying 
interoperate .  Ask  specifically  about  version  numbers  and 
system  configuration,  not  just  the  X.400  system. 

•  Watch  out  for  updates  and  upgrades.  Test  everything 
before  you  install.  You  need  to  test  compatibility  all 
over  again  if  one  component  changes. 

•  Backbone  designs  are  usually  more  efficient  to  manage  than 
point-to-point  gateways,  as  they  have  fewer  interdependent 
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components   and   less   equipment,   reducing   maintenance 
requirements . 

Finally,   evaluate   the   administrative   interface  and 

functionality  of  the  systems.   It's  a  demonstrated  fact  that 

an  easy-to-use  interface  can  save  valuable  time  and  make 

troubleshooting  easier  by  orders  of  magnitude. 

C.   HOW  DOD  AGENCIES  CAN  ACHIEVE  X.400  FUNCTIONALITY 

DMS  is  not  scheduled  for  completion  until  the  year  2007. 
The  X.400  messaging  portion  may  be  implemented  as  soon  as  the 
year  2000.  In  the  interim,  with  the  basic  premise  that 
X.400/X.500  standards  will  be  useful  for  any  DoD  component  to 
incorporate  into  their  communications  architecture,  components 
may  obtain  X.400/X.500  services/functionality  by  using  any 
one  or  a  combination  of  the  methods  mentioned  in  Chapter  III. 
It  is  important  to  note  that  these  methods  are  strictly 
conceptual  and  would  rely  on  a  case-by-case,  thorough 
requirements  analysis  (including  a  review  of  any  existing 
contracts)  prior  to  any  implementation  plan.  The  following 
conceptual  scenarios  are  provided. 

For  agencies  that  are  light  on  mail  traffic,  public  E-mail 
providers  such  as  AT&T,  MCI  and  Sprint  are  most  cost  effective 
since  installation  costs  are  low  and  the  providers  take  on  the 
burden  of  integration  and  management  issues.  Public  E-mail 
providers  are  the  fastest  and  simplest  way  to  set  up  X.400 
connectivity.   The  agency  would  "subscribe"  to  a  messaging 
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service  paying  a  set-up  charge  and  a  "per  message"  charge 
based  on  usage.  The  public  providers  usually  include  set-up, 
configuration,  maintenance  and  support  as  part  of  the  service. 
In  addition  to  messaging,  they  also  provide  enhanced  services 
like  accounting  and  monitoring. 

For  agencies  that  know  they  will  be  a  big  player  in  the 
DMS  program,  i.e.,  they  have  a  large-volume  messaging 
requirement  or  their  mission  is  operationally  critical  to 
National  Defense,  the  Wal-Mart  implementation  provides  a  good 
example  of  how  to  build  an  X.400  backbone  on  an  already- 
existing  enterprise-wide  network  and  telecommunication 
infrastructure  (Refer  to  Chapter  V)  .  Basically,  the  DoD 
component  would  need  to  purchase  the  hardware  and  software 
needed  to  build  a  native,  in-house,  X.400  enterprise  system. 
The  advantages  of  this  strategy  include  complete  control  over 
the  E-mail  system,  its  security  and  performance. 
Additionally,  it  offers  better  integration  with  existing 
corporate  computing  and  data  processing  functions  than  public 
link  or  strictly  proprietary  services  do.  As  Chapter  V  points 
out,  there  are  a  number  of  vendors  such  as  DEC  and  HP  that 
provide  all  the  components  needed  for  storing  and  routing 
X . 400  messages . 

Finally,  agencies  that  (1)  have  a  number  of  E-Mail 
packages  that  currently  can't  talk  to  one  another  (or  it's 
"addressingly "  very  painful  for  them  to),  and  (2)  are 
connected  on  a  LAN  or  WAN,   need  a  series  of  gateways.   Most 
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PC-based  E-Mail  vendors  and  minicomputer  and  mainframe 
computer  messaging  systems  have  X.400  gateways  between  their 
proprietary  messaging  systems  and  X.400.  If  any  of  the  E-Mail 
packages  do  not  provide  X.400  connectivity,  the  DoD  component 
may  have  to  procure  another  vendor's  compatible  X.400  gateway 
product.  For  example,  a  number  of  third-party  vendors  such 
as  Retix,  DEC,  World  Talk  and  Soft-Switch  provide  X.400 
gateways  and/or  servers  for  connecting  dissimilar  messaging 
services.  These  products  support  not  only  a  wide  selection  of 
proprietary  protocols  but  also  provide  the  message  handling 
agents  (UAs  and  MTAs )  required  for  sending  X.400  messages. 
Some  of  these  products  include  directory  services  that  tie 
together  dissimilar  E-mail  directory  formats.  If  the  agency 
has  strictly  LAN  electronic  messaging  requirements,  they  will 
not  need  a  gateway  for  UA  and  MTA  conversion;  but,  it  is 
highly  unlikely  for  an  agency  to  have  strictly  local  messaging 
requirements.  The  LAN  E-Mail  market  is  dominated  by  Lotus 
Development  Corp . ' s  cc:Mail,  Microsoft  Corp . ' s  Microsoft  Mail 
and  WordPerfect  Corp.'s  WordPerfect  Office,  in  that  order. 
Their  specific  attributes  are  listed  in  Chapter  III. 

D.   SUMMARY 

Creating  a  global  messaging  standard  that  transparently 
unites  all  disparate  E-Mail  systems  is  both  laudable  and 
possible  with  X.400  and  its  directory  counterpart,  X.500. 
This  thesis  provided  technicians  and  managers  alike  who  are 
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associated  with  an  E-Mail  system  with  a  basic,  thorough 
discussion  of  the  CCITT  X.400  family  of  Message  Handling 
Standards  and  a  brief  definition  of  the  associated  CCITT  X.500 
Directory  standard.  Implementation  issues  were  extensively 
discussed  and  illustrated  using  published  technical  reports. 
Showing  the  broad  scope  of  these  standards,  examples  from  both 
DoD  and  industry  were  provided.  Within  DoD,  native  X.400  is 
required  as  part  of  the  E-Mail  portion  of  the  global  Defense 
Message  System.  Within  industry,  X.400  is  required  for 
international  companies  to  maintain  a  competitive  edge  as 
shown  through  a  very  successful  retail  store's  current  X.400 
implementation,  Wal-Mart  Stores  Inc. 
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APPENDIX   ACRONYMS 

AAME  Automated  Multi -Media  Exchange 

ADI  AUTODIN-to-DISN  Interface 

admd  administrative  management  domain 

AFAMPE  Air  Force  Automated  Message  Processing  Exchange 

AIA  Aerospace  Industry  Association 

AMHS  Automated  Message  Handling  System 

AMPE  Automated   Message    Processing    Exchange    and 

Telephony 

API  Application  Program  Interface 

ARPANET  Advanced  Research  Projects  Agency  Network 

ASC  AUTODIN  Switching  Center 

ASD  Assistant  Secretary  of  Defense 

AU  Access  Unit 

AUTODIN  Automatic  Digital  Network 


C3I 

CCITT 

CSP 


Command,  Control,  Communications,  and  Intelligence 
Consultative  Committee  on  International  Telegraphy 
Communication  Support  Processor 


DARPA 

DDN 

DEC 


Defense  Advanced  Research  Agency 

Defense  Data  Network 

Digital  Equipment  Corporation 
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DIR 

DISA 

DISN 

DMS 

DMSWG 

DoD 

DPI 

DSNET 


Directory 

Defense  Information  Systems  Agency 

Defense  Information  System  Network 

Defense  Message  System 

Defense  Message  System  Working  Group 

Department  of  Defense 

Data  Processing  Installation 

Defense  Secure  Network 


EDI 


Electronic  Data  Interchange 


FTP 


File  Transfer  Protocol 


GOSIP 


Government  Open  System  Interconnection  Profile 


HP 


Hewlett  Packard 


ICP 

IFIP 

IP 

IS 

ISP 


In-Club  Processor  (Wal-Mart) 

International  Federation  of  Information  Processing 

Internet  Protocol 

Information  Systems 

In-Store  Processor  (Wal-Mart) 


LAN 

LDMX 

Mac 


Local  Area  Network 

Local  Digital  Message  Exchange 

Macintosh 
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MHS  Message  Handling  System 

MILNET  Military  Network 

MIS  Management  Information  Systems 

MROC  Multi-command  Required  Operational  Capability 

MS  Message  Store 

MSP  Message  Security  Protocol 

MTA  Message  Transfer  Agent 

MTS  Message  Transfer  System 


NIC 


Network  Information  Center 


OAS 
OSI 
QUA 


Office  Automation  System 
Open  System  Interconnection 
Organizational  User  Agent 


PLA 
PMSP 
prmd 
PSTN 


Plain  Language  Address 

Preliminary  Message  Security  Protocols 

private  management  domain 

Packet -Switched  Telephone  Network 


RFP 
RI 
RTS 
RUA 


Request  For  Proposal 
Routing  Indicator 
Reliable  Transport  Services 
Remote  User  Agent  (Wal-Mart) 


SDNS 


Secure  Data  Network  System 
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SMTP 
SUA 


Simple  Mail  Transfer  Protocol 
Simplified  User  Agent  (Wal-Mart 


TAIS 

TCC 

TCP 

TELEX 

TPN 

TUA 


Target  Architecture  and  Implementation  Strategy 

Telecommunication  Center 

Transmission  Control  Protocol 

Telephone  Exchange 

Tactical  Packet-switched  Network 

Training  User  Agent  (Wal-Mart) 


UA         User  Agent 

UNESCO     United  Nations  Educational  Scientific  and  Cultural 


WAN 


Wide  Area  Network 


XAPIA 


X.400  Application  Program  Interface  Association 
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